Subscribe
Share
Share
Embed
Next in our EC Methodology Series... services! Last time we talked about infrastructure. Today we’ll cover some key services we use to build our products and make them reliable.
Show Notes
You almost always need at least a few different “services.” One to expose your data to the app, another to authenticate users, and another to handle long-running tasks, for example. In this episode we break that down a bit.
💻 Connect with us, partner with us, or give us feedback:
hello@ephemerecreative.ca
🚀 Subscribe to learn more about our process:
🎥 Watch this series as videos on youtube:
📄 Read this series on our blog on Medium:
✉️ Subscribe to our newsletter:
Creators and Guests
What is The EC Methodology?
A series of short episodes where we talk about our product development workflow at Éphémère Creative.
Hey, and welcome back to our
series on EC's methodology.
Last time we talked about infrastructure
today, we'll cover some of the
key services we use to build our
products and make them reliable.
You almost always need a few services.
One to expose data to your app,
one to handle authentication and
authorization, another one to handle
long running tasks for example.
For most apps beyond
simple presentational ones.
You'll generally need at
least a couple services.
Sometimes these are things you'll
run yourself and other times they
are services you will pay for.
Here's a basic breakdown of the most
common services we'll either build or
configure and deploy for our projects.
First up authorization.
You'll need some sort of service
to handle registration and login.
We sometimes deploy keycloak, but
more recently we've been exploring
offerings from a company called
Ory and sometimes we use Auth0.
In some cases, we also just
use authentication, built
into a given framework.
An API
An API is how your app
interacts with your data.
We like to use a combination of
a tool called Hasura a framework
called Nest JS to build GraphQL
APIs on top of a Postgres database.
Workers.
You often need services to take care of
long running tasks like running reports.
These should be separate from
your API so that they don't slow
down the API when they're running.
We like to call them workers.
Clients.
These ones might be a bit
obvious, but they count.
These are the user facing applications,
which connect to all of your other
services, like a web app or a mobile app.
What are some common services you
use in your system architectures?
Follow us if you want to
keep up with this series.
We have a lot more to share with you.
We're constantly updating this process.
As we learn from ourselves,
our partners and our community.
If you think we could work together,
we'd love to partner up with you and
help you out on your next project.
See you next time.