proposal.md

You’ll hear this talk at Elm Europe in June 2017. Massive thanks to @chrisui, @stealthpig, @zsoobhan, @spryle, @dumbNickname and everyone else who helped shape this proposal. You guys are awesome!

 

how frontend microservices
help us stay flexible

Choosing the right technologies when starting a project is super important. It’s almost impossible to change the stack later on. Betting on Elm is therefore a bit risky. Right?

Not anymore! Now we can use frontend microservices to pick the right tool for every job!

Traditionally, single page apps are monoliths. Here’s a React app, that’s an Angular app and this one is in Vue.js. This way, early stack choices turn into a strong tie-in as the project grows. It’s pretty tricky to introduce Elm to a mature project running on a different technology.

In this talk, we’ll see how web components change the game. Finally, we can use the right tool for every job! We can introduce Elm bit by bit to any JavaScript app – or neatly embed JavaScript UI nuggets in an Elm app.

We’ll learn from the ups and downs of regular microservices, catch a glimpse of the culture that this approach has brought about at Lystable and leave with a strong toolset to make things happen.

 

 

---

 

 

speaker
Tomek Wiszniewski

 

Tomek created elm-live – a tool widely used and loved by the Elm community. As an engineer at Lystable, he crafts delightful user interfaces and helps shape an engineering culture which allows everyone to unleash their superpowers.

With a degree in Architecture (yeah, building houses), he’s been using Elm for a number of exciting University projects – and a mind-blowing app for makers coming to the market soon.

This is a very shiny idea =) I'd maybe call it something other than microservices, as people already have a clear idea of what this word means, and it's always backendy, so you might confuse people. Also you get the chance to invent a new term and get famous for it so why waste it?

EDIT: after seeing the talk it does make sense to call them microservices, as precisely the meat of the talk is highligting the points in which they compare to server microservices.

Thanks @marbru, yeah that’s the gist of it :)

I was surprised myself how much those have in common! It really feels like a single concept applied to two areas.

great talk at React Wrocław 🥇

Hey. What you write in the beginning of your description is not exactly true. Most of front end codebases really do have a monolithic structure, but some companies (like Spotify named by you during your talk in Wroclaw) use some production proven solutions to divide their code bases. During the talk we mentioned the iframes, as an alternative to web components based "browser only" solution, but there are other possibilities like Server Side Includes or Edge Side Includes. For example Varnish implements ESI and retrieves page fragments exposed under separate URLs (so it does not care who and how delivers the HTML). Some companies use Varnish only for fragments caching purposes (you can set TTL values per fragment), but with appropriate project structure it also provides you a way to compose web applications. When you compose on the server, you will not see that in the browser so sometimes it is not that easy to spot such things. The guys from compoxture made a short summary of available options in their rationale at the end of the project readme. Maybe you would like to have a look at that and mention those other approaches during your presentation to solve the problem and show how and why the one proposed by you will be better/worse etc. Imho comparisons are always nice. I would also mention what are the downsides (at least currently) for proposed solutions (e.g. web components are not SEO friendly at the moment). Google crawlers will probably index such pages properly as those execute JS, but there are many more crawlers around the web :) There are also some topics still to be addressed (e.g. app state management). I hope you find any of those thoughts helpful :D

Hey @dumbNickname, thanks so much for the thoughtful comments! The overview from compoxture is super helpful.

People have been doing frontend microservices that way for a while now – putting content from different applications together into a single, SEO-friendly HTML stream. Also, I hear great stuff about Varnish and ESI! My talk was mostly about developing single-page apps though, and in that case there’s little or no dynamic content that you want to deliver from the server.

But if you have a mixed “content + app” site – or want to boost performance through a server-side prerender – you can actually use the server-side caching/streaming tech you mentioned and frontend microservices alongside. 🎉 You can render content inside a web component and have it replaced when JS kicks in. That’s how the skeleton worked in the example app I showed. You can even pick up the prerendered DOM and reuse it in JS.

I’ve rephrased the intro to be 100% accurate. And I’ll definitely keep your other thoughts in mind. Thanks again! 😀

Hey again. No problem! 😄 Like I wrote before - I am glad that you found those thoughts useful. By the sample links you posted I can see that you heard about server side decomposition, which I have mentioned - so probably most of my points were not needed at all :P

Anyway, web components will trigger many new approaches, experiments and mixed solutions - what is a good thing. Passionate developers should check those paths, just as you do :) Obviously you will face new problems on your way :D There are also topics that will still need to be addressed, but ... not all at once. I think this will not be a silver bullet, but still remains an interesting approach.

Btw. I really find your skeleton app to be a nice example making its point properly. I also liked your talk on ReactJS Wroclaw - this is why I decided to share some of my opinions here (and exchanged emails with you).

Good luck at the conference!

Thanks! Hope they accept the talk 😄