When should you create a new API instead of modifying an existing API?

Matt

Hey ya'll,

An area I'm struggling with is how to determine making the call to either create a new API or modify an existing API. While it is relatively simple to create new APIs, the list of APIs just continues to grow.

I'll paint a scenario for example sake.

1. I've decided to have two user types - it will use the same user table but there will be a boolean for determining if the user is a standard user or not.
2. When creating company (table), the users that are NOT standard can be linked to a company through a relationship (company user)
3. Updating (POST) a company record to add a user should only be possible IF the user is "Yes" (a company user)

In the standard CRUD that is created when adding the company table and relationship field, I don't see an obvious function for checking that the user has 'true' for the boolean before allowing the user to be added to the record.

As I play with it I'm leaning towards (if possible) to allow the POST (edit) API to modify this single field (if necessary, such that the front-end is attempting it) but how can I allow the EDIT of the entire record but ONLY allow this one field to be edited based on the boolean being true?

AKA: 'Allow the user ID to be added to this record IF the boolean is true, otherwise do not…but still allow all the other fields to be modified as intended)?

With that said, it seems the Function Stack could be very large when considering many of the conditions across the entire ecosystem.

TL;DR: is there a set of considerations to take when deciding if you should add another API or use the Function Stack for an existing? If so, where does one learn?

Ray Deck

My approach is to be less REST-y and more ad-hoc for building backends. One endpoint per job to be done, rather than one per table. This allows the logic for the endpoint to be simpler and easier to debug.

Several months ago I was a guest on Automate All The Things where I expounded on this approach.

https://www.youtube.com/watch?v=Qdo6eQG6UhM

There are reasons to not go completely overboard with this approach. You don't want to just repeat things everywhere - that increases your maintentance work unnecessarily. And too many endpoints (as in more than several hundred) can become a memory bottleneck in lower-level Xano plans. So all this is subject to iteration - building, expanding, consolidating and learning as we go.

Like so much of nocode development - and that of software in general - it's an evolving process.

Matt

Reply test. (Not sure why my replies aren't posting).

Matt

Trying this yet AGAIN. [Two previous replies did not post and they are stuck in drafts but I can't even view them]

Thanks for the info Ray. In my example, I need to either create the user in one API call or have API calls where the second one adds the boolean.

Simple question here: which method would be the better* approach for creating/updating a user?

A) Dual APIs; 1 creates the user (without boolean), 1 edits the user after being created to add the boolean
B) Single API; 1 creates the user and, within the function stack, determines if/when the boolean should be set (which would only need to be set as true on a small % of the users)
C) Two Single APIs; 1 creates the user (with boolean as false), 1 creates the user (with boolean as true) - when these apply would be determined on the front-end

Ray Deck

The answer depends on the details of your use case. And sometimes that means we don't know until we're a little deeper into it. So: I would go with one that makes sense to you and seems relatively easy right now. Leave some powder dry so you can come back to it if it turns out to be a bottleneck as the rest of the app becomes clear to you.

Matt

Thanks for the reply, Ray.

Given the approach you've mentioned, I'd need to make two API calls.

1. User registers an account

2. A toggle or variable is included in the process that says 'Is Company' (something like that)

3. Based on this variable, I'd run the POST to create the user and a POST to edit that user, setting the "true" flag

OR, I just create a new API that is a POST for the user which INCLUDES the flag…but this only fires IF the front-end is true…otherwise it's the standard POST without this variable being set.

Does that make sense? If so which would you recommend?

A: Two API calls, one after the other

2: One API call that is specific for the scenario

Ray Deck

They're both fine, I would do that which makes the most sense for you, and leave powder dry to come back to it when you realize later there's some big reason to go the other way.

My own bias is to have more job-specific API endpoints rather than a few "REST"-y endpoints that I have to compose. But my even stronger bias is to lay something down today so that I can get the system to speak to me tomorrow. It might tell me what I did yesterday was wrong or introduces some big piece of friction, in which case I go back. "You will build this again" is the first line in the State Change mental model. Accepting this notion lets me move faster and make more interesting applications.

We often get this kind of fork-in-the-road question in our State Change office hours, and my answer is usually Yogi Berra's: "When you come to a fork in the road, take it." In those situations, I can also encourage people to just move quickly to see where the friction is and to bring it back to the group to alleviate it, since we solve those hard parts together.

Liz Anaya

Thank you for your response, Ray! 🙏

@Matt , sorry you were having issues posting replies! 😥 For some reason, the platform automatically flagged the post as spam, but it should be working fine now. If you reencounter this issue, please don't hesitate to reach out.