vast edge
if i was solely building a discord bot i would have my bot use the database directly. i also plan to have a dashboard so i'll have a backend service to power that dashboard
does it make sense for my discord bot to call the backend service for CRUD operations or any database operations even if they API won't be used on the dashboard?
should i have some common repo between my discord bot and backend service instead so they can share code?
round novaBOT
<@&987246841693360200> please have a look, thanks.
vapid pecan
id say it depends
if this is just a small personal bot or sth u really dont have to overengineer it
our tjbot also accesses his sqlite db directly
but if ur working on a bigger bot that's used on multiple servers, potentially also sold to others etc then it might be crucial to employ a proper and bigger scale architecture
like, this has less to do with what kind of service u program. and more with the scale of things
considering that u have a dashboard however it might be very useful to have a man in the middle who can coordinate db access
that said, i kinda remember someone asking the same question already a few weeks ago. if that was you, what has changed since then? werent the previous answers good enough already?
naive blaze
if i was solely building a discord bot i would have my bot use the database dire...
"should i have a single entry point? or multiple?"
is this what you're asking?
vast edge
"should i have a single entry point? or multiple?"
is this what you're asking?
yeah this is what i'm thinking of. the service will be the entry point for CRUD operations or really anything where the discord bot needs to access the database it would call the API instead
i want to understand the tradeoffs and pros and cons
common module used by bot the and service:
bot interacts with service
both of these ways feels similar, but with the first one both have access to the database
naive blaze
the more entry points there are, the harder it becomes to trace bugs
having everything funneled through a single system allows you to maintain that single system
theres also congestion concerns though
if everyone is using the same entry point, you could wind up with congestion
minor python
having everything funneled through a single system allows you to maintain that s...
I feel like it's the opposite 
naive blaze
with that said, pick your battles
naive blaze
I feel like it's the opposite <:Thinkfused:418796301522567179>
if they can only be allowed through a single system, you only have 1 system to maintain
minor python
if they can only be allowed through a single system, you only have 1 system to m...
but this system as much bigger
minor python
if instead of 10 endpoints, you have one
then all the code of all 10 endpoints must fit into one
and so it is much bigger
naive blaze
no, you can dissect requests & dispatch them across different services
minor python
not only that, but with one funnel, it is much harder to check for bugs, because it is harder to see what caused what
while for more endpoints, you have logs to tell you what caused what
naive blaze
you'll have logs either way
if you have multiple entry points, now you need to worry about things like authentication & sanitizing across multiple systems
instead of a single system
there are pros and cons
DRY type situation
if that single entry point fails, all things fail
thats one of the downsides
but if you need to apply authentication & data sanitazion across all systems, thats also higher maintenance
both have pros, both have cons, i'd say go for the single-entry route unless you expect a ton of throughput, or if you want other systems to be kept up if another system fails
former is great for smaller projects, easy to maintain, since you only have to maintain a single point, great for small teams. latter is better for larger projects, where a single failure cannot cause problems in the whole system (redundancy)
its really just a topic of redundancy