Recommendation for business logic - using supabase

Ask us anything
1

Hi all !

I’m at the point where I need to create a bit more business logic to validate data, manage errors and create some calculation workflows within my app.

I’m using supabase as DB and it’s been great so far.

BUT : I find doing the business logic through DB functions is kinda of a pain and I end up doing some logci in weweb which is baaad. There is the option to try out the new edge function but it also seem to be time intensive to create and deploy.

Any recommendation out there ? I’d like something simple to maintain and easily scalable. Wondering if I try edge functions…

Thanks !

2 Likes
2

Great question, let me check with the team and get back to you ASAP with a possible solution or resource that can help you.

3

AWS Lambda would probably be easier than edge functions

2 Likes
4

There are a number of Supabase wrappers out there for providing additional functionality on a more LCNC basis. Fastgen, Buildship and Comnoco come immediately to mind.

Xano competes in this space through the high-quality integration of the database and the no-code function stack builder for exactly the kind of control situation you describe. It’s not on supabase, but it does use PostgreSQL under the covers, which is the underlying technology in supabase too.

5 Likes
5

Thanks for this question @oblic and thanks for your responses @carrano_dot_dev and @raydeck. I was wondering this in the back of my mind for awhile and was prepared to do some deep research. You all took care of it in less than 5 minutes! :call_me_hand:t5:

6

@kanepaamauloa
Let me know if you have good experience with supabase wrapper.
I tried a few and it seem to requiert as much effort as using supabase DB function and-or Edge functions.

I didn’t like Xano, CRUD is easy but the rest is a pain, plus it’s expensive.
So I’ve been using DB function in supabase so far and it’s been working great.

Cheers !

1 Like
7

Thanks for the insight!

I’ll see what I can cook up. If what you say is true, I’ve also been considering creating my own API over supabase to handle some the more complex business logic. We’ll see how we go!

8

I think edge function are kinda meant for that.
But let me know which way you decide go and how you choose to implement :wink:

Cheers.

1 Like
9

Will do!

Yeah, I’m just not too versed in Typescript or Edge Functions. It would probably be faster for me to code something in a language and framework I already know and create a REST API off of that, but perhaps I should just dive into the ecosystem!

I noticed you saying you’re using DB Functions. Are you referring to Postgresql Functions or Edge Functions?

10

Using only Postgresql Functions so far.

They are using a procedural language (plpgsql) making it pretty easy and straight forward. But you have to have some knowledge of sql if you want to manipulate data and queries for your frontend needs. I found GPT to be of some use in learning some skills there.

You can also use Database Triggers, Views and such. It’s all native to the supabase environment and close to your DB, reducing latency, potential bugs, errors and future maintenance issues (which was a big concern for me regarding scalability).

Never did find a “wrapper” that would do better for less effort so it seemed illogical to use anything else.

As for edge function, I know you can write them in other languages, including javascript but haven’t tried it yet. Will probably have to go there eventually as development goes.

1 Like
11

Why is that ? :upside_down_face:

If you use correct RLS in Supabase, and factorize efficiently your WeWeb workflows, it’s seems pretty safe and not that ugly to do API-like stuff in WeWeb logic
(especially when the “code” is straightforward !)

On my side, although the logic I use is not that complex, I manage to work with a mix of :

  • Postgres functions (which are surprisingly efficient + easy to use because they are exposed within the supabase API)
  • WeWeb logic
  • I also use extensively the Supabase triggers / webhooks which allows to call a function or an external service with hooks !

TBH my only worry there is the ability to easily access this “code”, especially postgres functions that are not very UX friendly, even with the supabase wrapper.

I’m pretty happy with this mix though ! I try to keep the code very simple to avoid multiplicating functions everywhere, and it works fine

1 Like
12

I meant that putting Backend logic in the frontend (weweb) is bad.
I do some UI, UX logic within weweb, absolutely.

BUT, for the sake of portability and scalability, I’m not gonna start handling my data and processes inside weweb. Weweb is not reusable outside of weweb and it’s also not designed to offer any kind of performance for such process either. Data management and complex calculations/manipulations needs to be on some backend framework.

Like mentioned in my previous reply, I mostly use Supabase DB function which are pretty easy and straight forward. Might scale to Edge functions as my app grows in features and requirements.

1 Like
13

Maybe it’s just me but I find your answer a bit over-aggressive for an answer to someone sharing an experience and trying to bring some help :sweat_smile:

My point is (was ?) that the choice of the (WeWeb + Supabase) couple forces you to make more in your DB in terms of validation, permission rules etc … than you would on a (Front + API / Back + DB) more classical stack.
So in this specific context I think you can do more within your front app as long as the main critical rules are enforced by the DB config.

Anyway, good luck in your search :slightly_smiling_face:

1 Like
14

If you make 5 calls to 5 different tables from the front-end and manipulate data in between, you’ll get huge latency and it will perform worse on weaker devices. Then you’ll end up with a modal saving some more complex queries that takes 1s to close → Bad UX.

You’ll do the same with Xano/Fastgen/Backendless, just in no-code.

It really depends at the end of the day. I seen some wild stuff.

2 Likes
15

Didn’t mean to be agressive. English is not my first language.

I was only trying to bring clarity into something I though was bad conceptualisation and maybe misunderstanding on my part.

I come from an engineering background and I tend to look for elegant and flexible solutions. “Doing stuff” in the frontend is just not good practice in my opinion.

Just sharing my own personal input here, but ‘decoupling’ ‘business logic’ and ‘DB’ from the Frontend as much as possible seems to be the best practice for both performance and scalability issues. Doesn’t mean you can’t do it and making it work.

Hope this clarifies and thanks for your input.

16

No offense taken !

Yep, I do have the same background :sweat_smile: and worked for years as and with developers teams where I would also encourage as much as possible those good practices.

In my structure’s case, using Weweb is a sort of sacrifice to no / low code, mainly useful to have less experts users modifying business / display logic (under certain limits !).
So for us it’s a conscient trade to bring more logic into the frontend, making weweb editor the single place for “low code logic / display edition” (but indeed losing on scalability and other things) !

Have a good day

Nicolas

1 Like
17

I personally much prefer writing any complex logic in code compared to no-code, and use no-code only for UI only.

For this case, Edge Functions are working pretty well. I think it’s less work routing through a different framework, where you’d have to spend more time setting up the connections.

And much less complicated (although worse performance) than the DB functions which are hard to test/debug.

2 Likes
18

Coming back to this after almost 3 months…

And I like what @vasarmilan has mentioned because it’s where I’ve arrived.

There’s only so much that can be done with NoCode/LowCode.

WeWeb is brilliant for UI/UX. It is also great for implementing basic business/domain logic.

Similarly, Supabase, with its PostgreSQL functions and TypeScript functions (grouping them as functions in general), works great for implementing some business/domain logic. But when I approach a system as a whole, the interconnected of parts, I’m finding that the use of WeWeb + Supabase “Functions” hasn’t really met my needs.

Now, this is an opinion, but what I find most challenging with prototyping quickly is when tools get in the way or slow down iteration. In addition, thinking of the system as a whole, it becomes more challenging to develop complex business interactions when working with what feels like small component parts, speaking specifically about the use of “Functions.”

I know there’s a whole movement around service-oriented architecture, encapsulating things into atomic functions, but again, for me, with Supabase “Functions,” something seems to be missing. There needs to be a conductor, some sort of glue that brings it all together. Of course, I can continue to use TypeScript Functions to do that, but I’m beginning to feel that an API layer for conducting complex business operations is going to be the real solution for my use case.

So WeWeb + Busines/Domain Logic API + Supabase.

That’s just where I’m at right now. I’m still working with just WeWeb and Supabase. I’d love to hear more input on this. Admittedly, I can give TypeScript functions more of a chance. But I keep coming back to this question: Should I really be putting all my business logic there?

It’s the question of a Dumb Database vs. a Smart Database. I understand TypeScript functions can be seen as a layer above the database, but the coupling has me concerned.

Thoughts?

19

If you use the Fat Functions approach where you import various services, you should be able to create a pretty solid API on Edge Functions. So far I’ve not had a project that would require to spin up an API layer, as Edge Functions are supposed to do that, and I resort to the Edge only when the Postgres Stored Procedures are not enough for the job. This has worked so far for me pretty well.