Phoenix - to go with Umbrella or not? ( new project )

Hi

I have been looking into building a full fledged app with Phoenix.
My idea is to keep things decoupled and simple from the start (helps maintainability in the long term).

My backend will be a JSON api, which will be consumed by a completely separate front end (built with VueJS).
I’ve been exploring Umbrella apps, which seems like a good idea. I can definitely see a lot of problems it will solve (maintenance overhead, communication etc.)

In the end, my app will have services provided by each microservice, and each microservice will communicate with other microservices. My question is, should I start big (one monolithic app, and use Umbrella later to split) or incorporate an Umbrella structure right now?

I cannot seem to find a lot of resources on creating proper Umbrella apps based on Phoenix, but it is looking as if getting an Umbrella structure comes with complexity:

  • Should I have a central single interface to the database (for all apps)? If yes, how do we deal with a large number of schema modules here? (which could come in the future)
  • Are there any other potential pitfalls with this Umbrella design?

I would start mono and split later. You’re adding complexity up front that you don’t know you’ll ever need with preemptively splitting them. If you’re using Phoenix make good use of contexts and your code will already be logically separated and easy to split off later if the need develops.

4 Likes

It’s really up to you. If I have functionality that is coherent and a logical unit within a single app or possibly useful elsewhere I write (or extract) that code as a library. Libraries provide clarity for me. I’ve not done umbrella projects.

Hello, @itssasanka — Welcome to the community!

The ElixirTalk podcast has two useful episodes about this very topic:

I recommend checking those out those episodes for some good advice :slight_smile:

Summary: Keep it simple and start without an umbrella app. In most cases, it is relatively easy to split an application up into different applications later, if/when it becomes necessary.

3 Likes

Makes sense. However, Phoenix contexts are pretty much those “libraries” as far as I know, which is a good thing.

I am in pretty similar situation looking to build backend phoenix app with Vue frontend.
If I may ask you, how are you going to go about authentication? Sessions? Tokens? Which library is the most recommended for API backends?

I’d recommend having a look at Überauth and Pow.

Pow is session based and for REST API, which might be also used by mobile app later i am looking for something with tokens in headers. Uberauth looks fine but its more of a framework rather than a simple library, what do you think about Guardian?

I built one on my own, which based on OAuth 2, didn’t really feel I needed a library for what I wanted. Just to note though, it issues tokens to clients and the clients store them in LocalStorage (it can even be done more securely, but this is what I have for now.)

You can also just login your user, create a phoenix token and send that back to the client, then store it on the browser session and on vuex then wrap your calls from the client to always include the token.

We can definitely go with that (which is similar to using a JWT), however revokability cannot be controlled once a token is issued.

Not out of the box, but you can keep a list (e.g. in ets) of revoked keys (that you add to when a user logs out) and have a process that cleans them in a set interval of time (once their validation would have expired), and when verifying the request (e.g. on a plug) checking if the key as been revoked. I would imagine that most regular things probably don’t require revoking keys if they’re valid for max 1 day 'though

Aha, I see.

I haven’t got much hands-on experience with any of these libraries myself yet; I’ve just been toying around with them for a learning project. I know of a few related threads that might be useful.