(A thread)
Goals:
• Fantastic end-user experience
• Build as little as possible
• Speedy development
• System resiliency
• Easy for a solo dev
First part is a specific stack, but the rest is stack-agnostic.
Users expect rich UIs that are easier/faster to build/maintain with React. It's now a proven & boring technology, adopted everywhere from startups to enterprise. If there’s a chance you’ll need native apps, use React-native-web to run all code on every platform.
Next.js (React) or Nuxt.js (Vue) provide an incredible environment for building UIs. You don’t need to muck with Webpack or scream at Babel. The Chrome team is actively working on Next.js to make what’s very fast, even faster.
You can build an entire UI without writing any custom CSS, because it gives you Lego-like CSS pieces you can combine in any way. @tailwindcss or a CSS-in-JS combo of Emotion + Theme-UI make CSS so easy.
adamwathan.me/css-utility-cl…
GraphQL is the modern replacement for REST that simplifies development at all levels and makes it easy to stitch together all data sources your app needs. It’s many times better than REST for partners & users, prompting Github, Shopify, and many others to switch.
They are more resilient, easier to maintain, and more scalable than an EC2 instance. The GraphQL servers mentioned above are designed to work with serverless functions and make it easy to do so.
Typescript is statically typed Javascript and widely adopted. It's easily worth 1,000 unit tests. You’ll code faster and with more confidence. IDE code completion allows you to stay in flow without looking up methods or data attributes.
GraphQL and Typescript enable automatic code generation for data fetching. Define the data you need, and it generates the function for fetching the data, including strong types for IDE auto completion and compile safety.
You need User, Team, and Account models. A User can log in. An Account pays the bill. A Team owns resources. You don’t have to expose team functionality at the start, but you’ll almost certainly need it down the road.
This environment as identical to production as possible except for a different database instance. This allows you to test breaking changes in an isolated environment where you can mess stuff up all day long and not loose customers.
Set up tests at the start. For each major feature, write at least one end-to-end integration test. Add a git hook to run tests on git push to catch problems early. For JS, use Jest to run tests and Cypress for end-to-end tests.
You want every commit to master to trigger an auto test run, & if successful, to trigger an auto deploy to production. Set up a staging git branch that also auto runs tests and deploys to staging. Deploying to production is then just a git merge from staging to master.
When receiving webhooks from other services, save the webhook in its own database table, and trigger an event to process it asynchronously with a serverless function. This minimizes the chance for a third-party to DoS your app (this does happen).
Use a third-party service like @auth0 or AWS Cognito. It’s much more secure. It allows you to turn on 2-factor authentication, social media logins, and more with just the flip of a switch.
Use a third-party service like @Chargebee or @Outseta. You need all the stuff Stripe doesn’t give you like in-app billing UI, ability to update credit card, and switch plans, but you shouldn’t spend time building it yourself. Focus on your product.
Use @Imgix or @Cloudinary to load images at the exact size and resolution you need instead of doing your own image processing.
@postmarkapp is top of the line and affordable. Use this for password resets, email reports, onboarding emails etc, but not for marketing.
You need a separate service for sending things like marketing campaigns. @Mailchimp or @Userlist fit the bill.
Use @UptimeRobot to continuously ping your server and alert you if something’s wrong. Add a dedicated /health endpoint that checks your DB connection and returns 200 if everything’s ok.
User’s will NOT tell you about most problems. Use a service like @getsentry or @honeybadgerapp to track both frontend and backend errors.
Use a service like @LogDNA or @papertrailapp to collect logs from every place you have code running. These services make it a breeze to slice and dice your logs and pinpoint production issues. Without these, it’s a severe headache to debug production issues.
To understand how your users use your app. How many people are using your app every day? Every week? Who stopped logging in recently? Which customers are the most active? What feature should you improve? Use a service like @Amplitude_HQ or @Outseta
Your users need to know what features you are adding so they can take advantage of them. Use a service like Beamer, Headway, or @changefeedapp