Adapting to a platform

In a simplistic way, we can see web frameworks as convenient functions that take your app as input and return deployable artifacts. GatsbyJS generates static HTML, CSS, and Javascript that platforms like Netlify know how to deploy. Rails generates static assets and provides an entry point to run a process on a platform like Heroku. Note that the artifacts need to be adapted to the deployment target. Heroku does it through buildpacks and Procfiles that instruct the platform on building and running a server. Netlify achieves the same through a configuration file where developers describe how to build and deploy their websites. Traditionally, the adaptation process has either fallen on the platform or developers’ sides (e.g. through a CI deployment pipeline)

What if frameworks have adaptation as a built-in primitive? That’s what SvelteKit provides through Adapters. It’s an API for third-party developers to define how to adapt a SvelteKit app to different hosting providers. For example, the netlify-adapter adapts the output to Netlify and does things like turning endpoints and SSR pages into functions that run on-demand. Because the framework allows SSR, CSR, and static rendering, a SvelteKit project can contain the web app, documentation website, and marketing and landing pages. Cool? Isn’t it. Adapters decouple the deployment platform from the framework to prevent vendor-locking.

I’m still new to the framework, but I think its concepts are powerful, and adapters are an excellent example of that.