Design Patterns – Software Architecture for App with API Back-End

apidesign-patternssequence-diagram

I have been searching the net for an answer, but I was not able to find a similair question nor answer. So here I am.

I am developing an app where a user can take a picture of a car and they will get back the car brand and possibly a model.

Currently I am using an API as a back-end to recieve the picture, the API will send the picture to a different API which can recognize the car + model. The response will be sent back to my API, I will sanitize the response and send it back to the app.

I was wondering if this would be a good structure or if I could do it like the picture below.

Current application flow:

What I think might be better but less secure application flow:

New application flow:

My question here is, is it possible for the last application flow to be implemented so I don't have to send a picture twice, but I can just send a picture from my app directly to the API that is not mine, get the token back and get the response that way. My concern with this is that I will need to give people with an App my API_key so they can do requests to the Api that is not mine. There is the possibility of using oAuth1 but I don't know if my api key will be secure enough that way, any advice will be appreciated.

EDIT1
My sanitize function in my own back-end api is too big to implement in the App itself.

Best Answer

There are three (edit: four) reasons I would not go for this.

You are reliant upon the third party API to do additional integration with your API, to return a token, and then provide a response from a token not an uploaded image. So you'd need to know they would provide that integration and maintain it
You're getting your clients (the app) to make two API calls to do a single operation and that would need documenting because it isn't a standard concept, so you'd need to document and provide support for it.
Dealing with authentication is hard and requires time and thought. When you can avoid it, I'd always try to.
If you're giving your API key to your clients what's to stop them following your procedure and not just directly calling the image analysis method directly and short cutting you?

I agree with other commenters that option 1 is sensible. You're keeping your implementations as a black box to your clients and one day, when you find a better third party API which is faster and cheaper and does better recognition - you only need to update your API and don't need to care about that from your clients point of view.

If you're worried about transfer speeds, why not look at some image resizing on the client first, or have your client upload to something like Azure blob / Amazon S3 storage and just pass around URLs?

Related Solutions

C# ASP.NET MVC SoC – Design Decisions for Backend Objects

This is a common point of confusion with ASP.NET MVC, mostly because MVC is so un-opinionated about how your application should be built. @MikeSW makes a good point: it's important to realize that MVC is a UI pattern, but more importantly, you should realize that it's just a pattern. It's not law, the framework won't complain if you do something different.

I'll tell you how a typical ASP.NET MVC project develops, because there's a reason why it's typical. You have domain layer. That could include a DAL, services, whatever. For many, this is just Entity Framework, but if you're building anything larger than a ToDo app (and maybe even for that), you're going to want to abstract that out.

Now, because MVC comes with Entity Framework, the common assumption is that your entities are your Model of MVC. That's a very poor assumption. Entities are dumb - intentionally dumb. They're not really intended for anything but data transfer to and from the database. A Model should be the opposite of that: it should hold all your business logic for the application (or at least that piece of the application. In that way, a view model is closer to the Model of MVC, but even then, it's not all-ecompassing. I would say that your Model is some combo of your view model plus your domain layer. Regardless, the point is that if you intend to use entities as an end-to-end, be-all-end-all Model, at some point, it will bite you in the glutious maximus. It's not a matter of if, but when.

My recommendation is the following:

Database -> Entity Framework -> Domain Layer -> Controller -> View Model -> View

And, back the same way.

Your domain layer will utilize Entity Framework (but this could later be substituted with a Web API, WCF Service, whatever) to retrieve your entities. Your controllers will map your entities to view models and vice versa and then your views will use your view models. For POST operations, your controllers receive view models, map those to entities, and then send them through the domain layer down to be created/updated/whatever. All big MVC projects are built like this or in some minor variation of this, and for a good reason: if you don't do it this way now, you'll only have to do it this way later, with much more time and expense on the tail-end.

C# API – Let Xamarin Clients Listen When Server Sends an API

Check out SignalR. It enables long running web connections that let you send events from server to client.

If you're making an app, maybe you could use Push for the events?

Or you could even make a simple loop that checks for updates. Kind of like your idea, but separate the check from the data fetching for performance.

Yet another way is to use some kind of socket instead of ordinary http. Since you build an app you are not limited to web techniques.

Best Answer

Related Solutions

C# ASP.NET MVC SoC – Design Decisions for Backend Objects

C# API – Let Xamarin Clients Listen When Server Sends an API

Related Topic