Modern websites, and their composition is, in short, some static HTML (some times more, sometimes less) with a bag full of JavaScript slapped onto it all.
It was not always like that, with pages fully rendered on the back-end. Even though terrific for the SEO and load times, when you wanted users to visit multiple pages during one visit, it was not the best for the user experience.
The ability to output dynamic content also suffered. The solution? Mix both of the approaches. That’s why The Guardian, a popular British organization, creates fully static pages with “islands” of JavaScript (small, dynamic elements in the middle of the sea of static content). Interestingly, they are using their own, open-source, solution. See more details here.
The Bottom Line
More organizations, than just The Guardian, realized that, to achieve optimal results, they have to find a healthy mix of the approaches in an effort to both please bots and users. One has to also remember about all people who disabled the execution of JavaScript. It used to be the case, until recently, that if one disabled the execution of the popular programming language, they would get an (almost) blank page.
Even though the British newspaper had numerous options to choose from (e.g., Astro), they chose to create their solution, which you may see on GitHub.
In case your production code is running on .NET 5, it might be the right time to consider switching over to .NET 6. Unlike version 5, the newest iteration is a “Long-Term Support” release, meaning, you can forget about having to switch for quite some time. If you need an incentive to undertake the migration, then you might be interested in the performance gains one gets out of the box.
The Bottom Line
A conscious choice not to update your tools can have dire consequences for your company and your product. Putting off updates is like taking loans: you have to pay for it, with each major version ignored acting as another loan. You may quickly realize, that soon, you will not be able to afford the interest rate on it all. So yes, in the short term, you will be fine. In the long-term, you won’t.
Salesforce, the company best-known for its CRM, announced the introduction of an GraphQL API last week. The solution, scheduled to reach the beta status in the summer of ‘22, “allows developers to interact with the Salesforce Platform through GraphQL, providing a new way to create rich, performant mobile and web applications.”
Ben Sklar from Salesforce created a great analogy to compare traditional REST APIs, and GraphQL:
Imagine you’re out at your favorite restaurant — in this case we’ll call it the RESTaurant. Your waiter comes over to your table and asks, “What would you like to order?”
You reply, “I’ll take the ravioli, but please, no cheese on top.” To your chagrin, your waiter explains, “The cheese has already been added and can’t be taken off. You’ll get the ravioli with the cheese, or you’ll have to order something else.”
Herein lies a fundamental problem with traditional REST endpoints — you as the client can’t change what the Cheese Ravioli Endpoint returns back to you. Had this restaurant been the GraphQL Restaurant, you could order ravioli without cheese.
The Bottom Line
GraphQL was supposed to be the end of the traditional REST APIs. As one may realize, it is not the case. Simply enough, each solution has its use cases, and areas where it will struggle. GraphQL was supposed to get rid of all the different API endpoints, to improve the cooperation between the back-end, and the front-end teams, to customize what endpoints return, and more. Yes, the solution achieves these goals, though the need for the more traditional approach did not disappear. If anything, developers now have more options.
Go, one of Google’s programming languages, recently underwent a major change. Something that developers often complained about a makeshift support for generics. The developers of Go listened, and introduced a significant change. Now instead of interface{} one specifies the type to be T with a possibility to restrict values one may use.
The Bottom Line
This is one of the most significant changes, if not the most significant change, in Go, ever. Even though, previously, it was possible to achieve a similar result, now the resulting code is safer. All thanks to the ability to restrict what types one may use.
This is how one uses generics in their Golang project:
For more, please watch this video
.svg){kind=small}
