Kyle W.

JavaScript Meetup

On the 27th of October 2022 I attended a Frontend Developer Meetup in Amsterdam. The night consisted of 4 talks and some networking, organised by Passionate People and hosted in the ING office space. These are my takeaways from the night.

Rendering Strategies – Tim van Bergenhenegouwen

The talk started off with a nice history of trends around web rendering, showing the ping-pong of doing more work on the frontend, and then doing more work on the backend. We have a lot of options to choose from because of this, and there is no one-size fits all solution. It is better to choose a strategy based on your needs:

• SEO

• Performance

• Speed

• Dynamic content

• Global Users

• etc

There is a lot of information on these strategies as well as many choices you can make within these strategies, such as framework or what combinations you want to use. Here are some I took note of during the talk, many of them often referred to by their acronyms:

• SSR: Server side rendering

• SSG: Server side generation

• SPA: Single page application

• PWA: Progressive web app

• Offline first

Things mentioned in the talk that I would like to look into further

Is this the end of E2E – Tobias Kuppens Groot

Tobias covered a brief summary of what E2E testing is, why we use it, and why it might not be the most valuable use of a developer's resources. We use E2E testing to validate communication; communication between frontend and backend services, between separate backend services, external integrations, and communication between user and UI, all at once.

Because of this, tests need to be run monolithically. Everything is deployed and tested together. If any one of these pieces of the monolith change, then the results of the test becomes stale and the next tests will (should) fail. This is flaky, makes tests hard to refactor and slow to fix and debug. On top of this, it relies on the relevant test data to be present in the environment you are testing.

Their suggestion is to add another layer to the bottom of Martin Fowler's Testing Pyramid: the type-safety system. You use it to confirm that you have valid code and provide confidence that the code will work. It is extremely quick because you get feedback as you're writing the code, whether as an IDE integration or in compile errors when building the code.

In order to use this new pyramid layer to validate communication between the frontend and backend, you can use type generators for API specs. This tends to work better with an API-first design, as you can be sure that both frontend and backend are holding up their end of the contract. With these API generations, you can also rely on a live service layer, allowing you to concentrate on the UI without worrying about the details of the network requests. Another advantage of this is that it can be mocked out in tests using something like Mock Service Worker.

Things mentioned in the talk that I would like to look into further

Event-driven Dependency Injection - Matius Fernandez Martinez

This talk was about creating a solution for dependency injection (resolution) when working with web components, since with most modern frameworks you get it out of the box. Dependency injection helps with inversion of control, where a framework will call your custom code and provide services rather than you calling the framework methods to get services.

The solution is smart in its simplicity. Since you’re using DOM elements, you can use the event system to bubble up events to ‘provider’ custom elements further up in the tree. It also all works synchronously, so dependencies are resolved without waiting. You can see the full repo with this implemented here: https://github.com/thematho/lit-elements-dependency-injection-demo. It utilises mixins to avoid boilerplate with setting up the event listeners and dispatchers.

Effortless full-stack type-safety with pure TypeScript – Jasper Haggenburg

This talk was by the creators of a new frontend/backend framework called Phero. Similar to the 2nd talk, this framework utilises type generation from backend APIs to provide better confidence and developer experience when integrating frontend with backend. The twist here is that you don't need to spec out the backend services, instead Phero utilises the typescript compiler to generate the interfaces from the types used in your backend functions. On top of this, it also generates errors for custom errors you use in your backend functions. I hadn't heard of RPC (remote procedure calling) until this talk, but it makes a lot of sense when writing web applications.

Lots of questions from the audience revealed there is much still in planning, as the framework is quite young still. Things like API versioning when making breaking changes between interfaces, automatic documentation generation and custom HTTP status codes are all things that they are looking to work on moving forward.

Things mentioned in the talk that I would like to look into further

Last thing

This was the first meetup/tech talk I had been to in a while, and it was fun to get back into the swing of things. I got to chat to some very friendly, like-minded developers, and I came away with a lot of new things to try. Not to mention, it inspired me to start this blog!