Help architecting three Elixir modules and one Phoenix module

Phoenix Forum Questions / Help
,
1

So, now I’ve found myself working on four greenfield Elixir/Phoenix modules!

The project aims to be a port of the functionality in the Cloudflare example project, orange. Orange is largely a typescript monolith, whereas the goal with the Elixir port is to have clean abstractions.

This diagram mostly shows how the four modules will connect:

Feedback welcome (WIP, new Elixir dev) - I am very much open to feedback from more experienced Elixir/Phoenix engineers. Thanks!

For context on the direction: the complete port of Cloudflare’s sample app, orange, will encompass the four modules here, as well as a client Phoenix app that uses them.

2

It’s not completely clear from the github document, however are you planning on having 4 separate runtimes? If yes, then what is the motivation behind that?

1 Like
3

I may have set up the modules incorrectly a bit… so if you see supervisors on the elixir modules that may be mistake.

Def. open to consolidating it down to one or two modules instead of four

4

That was also my first sentiment, starting off with 4 separate GitHub repos might make things more complex than necessary.

The Phoenix one, per README, also wants to be a library and not a typical Phoenix app.

Maybe there are good reasons to go into that upfront separation approach, however I’d consider first getting a single Phoenix app working first, then extracting parts from that as needed.

2 Likes
5

Well, the idea is that the core would handle configuration and connection. Cloudflare has extensive services, so the idea is that the core module could be expanded to abstract away the plumbing and let the module try to be as minimal and streamlined as possible, without having to think about configurations, keys, url’s, etc

The idea then is to build the ecosystem of cloudflare elixir modules on top of the core and presumably use a lot less code, and/or at least keep much of the code out of the individual modules. Calls (Cloudflare’s video infra) is just the first one.

6

What do you mean by modules? Do you mean service (a separate runtime) or a library or perhaps a OTP app?

I would personally highly recommend to keep everything in one runtime for the time being, unless you need independent scaling of those parts, but it doesn’t seem like this project aims to do heavy processing.

Completely agree, I would personally go with a monorepo approach if having a single codebase is not possible and reference the packages as local dependencies:

{:local_dependency, path: "path/to/local_dependency"}

Allows for easy prototyping and you can split them up later in a few minutes if you decide to.

1 Like
7

I made a mistake when I used the word “module”. I really meant each individual project or code repository. I wasn’t sure what the best way to organize this code was.

My goal is to have several separate Cloudflare projects that can be used on their own. The “core” library is just code that’s shared by some of these projects. It’s not really a module in the traditional sense. I’m trying to create reusable code, and the ex_cloudflare_calls library seems like a good place to start. I think it’s useful to have a dedicated Elixir library for interacting with Cloudflare’s APIs.

The ex_cloudflare_phoenix project will make it easy to integrate Cloudflare with Phoenix LiveView.

The three Elixir libraries don’t store any data themselves, but someone might want to use them in a regular Elixir app without all the extra features of a full Phoenix LiveView application. So I might need to change the code and remove the supervisors. I’m still new to Elixir, so I’m sure I’ve made some mistakes. I’m happy to hear any suggestions or corrections. I’m just explaining how I arrived at the decision to create four separate repositories.

I might actually combine some of these into one or two repositories, so I’d really appreciate your feedback.

1 Like
8

Welcome to the community and don’t worry about trying things out. What may seem a mistake one day, the next day turns out to be valuable experience and learning.

Thanks to you I learned about Cloudflare Calls :slight_smile: Thanks!

2 Likes
9

Thanks :slight_smile: I’m seriously considering the advice given thus far. I’d like to create a number of Cloudflare-related modules that will share a common (stateless) Elixir library for low level plumbing and configuration. That was supposed to be ex_cloudflare_core. What’s the best way to do this?

Alternatively, I will seriously consider just rolling everything into one repo, if that’s the convention. However, I strongly believe that it will be better to have isolated modules. Cloudflare has a lot of interesting functionality that is ripe for integration into Elixir and Phoenix. I could see a monorepo becoming cumbersome.

10

Thanks again for the push. I did the right thing and created an umbrella app.

cf_ex

Elixir libraries for Cloudflare edge computing services. Battle-tested BEAM implementations of Cloudflare Calls and Durable Objects.

Structure

This project uses an umbrella structure with the following applications:

  • cf_core: Common plumbing and utilities for interacting with the Cloudflare API.
  • cf_calls: Robust Elixir client for the Cloudflare Calls API.
  • cf_durable: High-performance interface to Cloudflare Durable Objects.
11

The details of umbrellas escape me (stopped using them years ago) but that might not be your best option; IMO you can have cf_core be a standalone library and then have all others depend on it. It’s pretty standard.

Should you require ease of development locally you can always temporarily change your dependency definitions to path.