How to build a backend that can return raw data (for testing) as well as html for templating

Phoenix Forum Questions / Help
,
1

How would one architect an app so that you can test the core functionality without worrying about the templating noise?

My guess would be to separate your ‘web’ (routing etc) service from your ‘api’? If that’s correct, what’s a recommended way of doing so?

Sorry I know this is broad and it probably depends, so if it helps, a bit of context:

I’ve been working in Phoenix for the last 2 years and am really enjoying it so far. Having said that, I don’t have much other experience building web-apps so my conceptual thinking & confidence are probably below where they should be.

Over the last 2 years I’ve built a monolith application that is entirely SSR relying heavily on phoenix (postgres/redis). I’m starting to run into some problems due to some poor implementations, poor design decisions and changing requirements. Therefore I’m looking at how we could change things if we were to rebuild.

2

Is this structure generally what I should be looking at?:

CLIENT <— http —> WEB/ROUTER <— dependency —> API <— http —> DATABASE

What is the role of the WEB/ROUTER service/application in this case?

Can/should the API be split into sub apps? And do contexts tie into this structure?

I guess this is a badly posed question, hence the lack of responses. Maybe this would be better:

Does anyone know of any good open source projects that have a good architecture to follow? I’ve checked out hexpm so far which has been really cool.

How does one go about learning this stuff without a senior dev?

3

Have a look at:

i.e. create a UI independent OTP application that deals with the business logic and data which a Phoenix app can then use as a dependency - acting only as the web front end.

4

That’s great thanks. Some good reading & links in there.

I’d love to find some open source projects to take a look at which are structured in this way.

I’ll update here if I find any.