Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Independently together: 
better developer experience & App performance

Independently together: 
better developer experience & App performance

Over the last decade, products have moved to web-based applications, typically with the help of strong JavaScript libraries. Bigger, single-page applications were born, coupled with product teams and their road maps. But this marriage added additional complexities to how we build – and how we deploy. We’re moving into a new era – one in which we change the how of building to ease these development and frontend architecture struggles.

Enter micro-applications: single-page creations that create independent applications that can be managed separately, built separately, and deployed separately – without blocking each other: They essentially move together, independently.

While developing web applications, 
we have some common asks! There are lots of different requests coming from each team for their application and product & software development lifecycle. We can categorise those requests into a few groups.

I want to deploy anytime I need! I built my new feature or fixed a bug for my page, did my tests and validated it. Now I want to deploy it to production. But wait… I need to wait!

I want to have a faster pipeline. Let's talk about the pipelines. They were fast in the past, but as my app grew and got more complex, now my pipelines take hours!

I want my application loads faster. My application has lots of files and resources. I use service workers to precache. I use best practices and lots of complex tooling and build steps, but it takes time to load, and I cannot get an instant load time!

I want to have a faster local environment. I do not want to even talk about my local environment. Starting up the local gives me enough time to brew my coffee!

Monorepo: That's how we like to manage our code
Over the years, for developing applications, we got a habit of using monorepos. Since teams see lots of benefits to using them, for most organisations, it became a de facto.

Spa: We like javascript, and who wants A full page refresh?
JavaScript conquered our web application development. We like to build single-page applications to prevent full-page reloads since we just need to change a part of the page for each navigation, right?

SPoF: Multiple different aspects can take the entire app down as a single point of failure.
All these singularities tend to become a single point of failure for our application. A small JS error in the page can block the whole navigation, or if the shell is broken, you cannot even load the application.

Multiple teams working on the same app add additional complexity to the tech stack. Not to mention the tooling complexity to manage all teams and all different features, needs and expectations

Every single thing becomes dependent on each other. When we add all the above, everything becomes dependent on each other. You need to plan every move carefully to avoid breaking things.

Multiple alignments, complex tooling, longer pipelines, slow releases, different roadmaps, lots of blockers… This is a lot, usually a lot more pressure on our day-to-day work than we need.

Everything is in the same box. Let’s check what we have in this box very high level and how we can make it more manageable.

80d92d5d0bd0170aebf6e07589a0b571?s=128

Bilal Çınarlı

June 15, 2022
Tweet

More Decks by Bilal Çınarlı

Other Decks in Programming

Transcript

  1. MICRO APPLICATIONS INDEPENDENTLY TOGETHER: BETTER DEVELOPER EXPERIENCE & APP PERFORMANCE

  2. BILAL CINARLI Sr. Engineering Manager @RapidAPI @bcinarli

  3. While developing web applications, we have some common asks!

  4. I want to deploy anytime I need!

  5. I want to have a faster pipeline

  6. I want my application loads faster

  7. I want to have a faster local environment

  8. MONOREPO HOW WE LIKE TO MANAGE OUR CODE

  9. SPA WE LIKE JAVASCRIPT, AND WHO WANTS A FULL PAGE

    REFRESH?
  10. MONOLITH HOW WE USUALLY BUILD AND RUN OUR FRONTEND APPLICATION

  11. SPOF MULTIPLE DIFFERENT ASPECTS CAN TAKE THE ENTIRE APP DOWN

  12. Multiple teams working on the same app add additional complexity

    to the tech stack
  13. DEPENDENCIES EVERY SINGLE THING BECOMES DEPENDENT ON EACH OTHER

  14. Multiple alignments, complex tooling, longer pipelines, slow releases, different roadmaps,

    lots of blockers…
  15. Everything is in the same box

  16. Monolith SPA Team A Team B Team D Team C

  17. Team D Team C Team B Team A Monolith SPA

    App A App D App B App C
  18. Team D App D Team C App C Team B

    App B Team A App A Router
  19. Team D App D Team C App C Team B

    App B Team A App A Router CDN for Common Libraries
  20. CDN for Common Libraries Team D App D Team C

    App C Team B App B Team A App A Router
  21. CDN for Common Libraries Team D App D Team C

    App C Team B App B Team A App A Router Cookies Local Storage
  22. In development, we do not have magical solutions, we have

    trade-offs!
  23. MICRO APP A SMALL SPA FOR EACH PAGE OR FOR

    A FLOW
  24. MICRO APP FULLY INDEPENDENT APPLICATION

  25. MICRO APP CAN BE DEPLOYED AND SCALED INDEPENDENTLY

  26. Split by responsibilities or whatever works in your organisation

  27. Independent apps have an independent development cycle

  28. Independent apps can deploy and scale individually

  29. Shared dependencies provide better caching and reduces the downloads

  30. Smaller apps load faster

  31. Smaller apps have faster local environment

  32. Smaller apps need smaller resources to run

  33. With a faster pipeline and local, improved developer experience

  34. Reduces your carbon footprint

  35. MICRO APPLICATIONS BILAL CINARLI THANK YOU @bcinarli