What is HTML All The Things?
HTML All The Things is a web development podcast and discord community which was started by Matt and Mike, developers based in Ontario, Canada.
The podcast speaks to web development topics as well as running a small business, self-employment and time management. You can join them for both their successes and their struggles as they try to manage expanding their Web Development business without stretching themselves too thin.
What's This One About?
Full-stack development demands both frontend and backend development skills, meaning one individual can spin up a website from the hosting, through the database management, and even the user interface. Recently, some people in the developer community have voiced their observations on how complex both frontend and backend development are on their own, stating that it's not really possible to be a full-stack developer if you want to maintain a high level of skill in all the technologies involved. In this episode, Mike breaks down a stack that he has recently started using that should allow him to provide a full-stack's worth of work through 2023.
Show notes
Next.js, Nuxt.js, SvelteKit
- These technologies are built upon React, Vue, and Svelte respectively and allow you to build full-stack applications in one repository
- They are packaged and served by a nodeJS server which allows you to tap into the node side and create node/Express API’s right from the save project
- This also allows the server to render all the content and serve it as static files (if applicable)
- Routing can also be file based like a regular static project running on Apache or Nginx
Prisma + TRPC + TypeScript
- One thing majorly lacking from the full stack web dev setup has been Types for your data flow.
- TypeScript is a way for JavaScript to have strong type declaration which essentially means right in your IDE (VSCode) you can assign a variable any time (Number, String, Object, etc) and wherever you use that variable again if you are trying to use for example a number as a String the IDE will catch that and underline it in red. If you hover over it will tell you what is wrong and where to fix it.
- It also allows you to have some crazy strong autocompletion A typical setup is a database communicated by a backend (think all typical CRUD operations).
- Then the Front-end communicates with the backend to send and receive the exact data it needs The thing missing from all this is that the Front-end never knows what data is stored in the backend so you just kind of have to try it and see if it fails
- Now imagine you have separate teams working on both, this can lead to major confusion and even production problems Ex. If the backend team removes an attribute in the schema without letting the front-end team know
- To solve this problem we can combine an ORM like Prisma
- A ORM is a database abstraction layer that allows easier communication with a database
- Imagine just writing simple JavaScript functions to fetch data instead of SQL queries And an API helper library like TRPC
- Which maps frontend requests to the backend APIs
- All using TypeScript
- With this stack: Next.js + TRPC + Prisma you can start to build TypeSafe data connections without a ton of custom work. Checkout Create T3 App for examples
- TRPC allows for a lot of Type inference from the ORM Schema (Prisma)
- So whatever data/types you declare in your schema, those types will flow all the way up to your Front-end without much custom work.
Thank you!
If you're enjoying the podcast consider giving us a review on Apple Podcasts or checking out our Patreon to get a shoutout on the podcast.
You can find us on all the podcast platforms out there as well as
Instagram (@htmlallthethings)
Twitter (@htmleverything)
TikTok
Top comments (3)
You could achieve the same thing with SvelteKit + Houdini. You get typesafety back to back, even though it is justb graphql, and your data could come not only from your backend, but from anywhere, Hasura, GraphJin, Postgraphile, Directus, Apollo, Strapi etc so what are the advantages of the stack proposed over typed graphQL?
With GraphQL you have to manage another layer. With this it's a basic REST api but with the type advantages of graphQL.
If your stack has a separate backend and multiple different front-ends then graphQL is 100% the way to go to achieve this.
Agreed. It would be great actually to compare the two approaches side by side, like lines of code, dependencies, implementation etc