64

Absolutely. For starters, you never know that somebody hasn't hacked into your connection and the reply you receive doesn't come from the API at all. And some time in the last two weeks I think Facebook changed an API without notice, which caused lots of iOS apps to crash. If someone had verified the reply, the API would have failed, but without crashing ...


40

Somebody else's API is your external interface. You shouldn't blindly trust anything that crosses that boundary. Your future debuggers will thank you for not propagating the other system's errors into yours.


17

Is your API-boundary also a trust-boundary? As you are communicating with a remote system, that's nearly a certainty. Even if the remote system itself might be trusted, the medium might not be. Failure to successfully and consistently verify all untrusted data may result in a crash in the best case, to silent hostile takeover at the worst. Is the API stable? ...


7

When you look at the most highly scalable web applications (or services) today, the problem wasn't ensuring enough threads that were available, but ensuring the whole system could handle the concurrent web connections required to service the endpoints. The biggest advancements in concurrent requests/second on one installation came from non-blocking I/O. ...


6

If you notice, most of these systems are setup in such a way that you're going to get some well known string input and have to produce some well known string output. At that point, they can take your code and run it as a plain old executable (in some highly disposable sandbox), testing via stdin and stdout while ignoring what language actually created the ...


6

Usually the naming of the layers depend on the architectural approach: The traditional layering is presentation / business logic / data access layer. Another popular variant is Fowler’s presentation / domain logic / data source layer. More recent architectures were inspired by the (data neutral) hexagonal architecture and use a more concentric idioms, ...


6

Perspective Rub your eyes and look at what you are discussing: a WebApp and a Server that communicate across a network. That is literally two separate applications with a network interface. In fact you have just reinvented the Thick client. Just instead of installing it on Windows, and compiling it from C++ you are writing it in JavaScript and installing it ...


5

Not validating user input... what is the worst that could happen? You accept a comment that will never be displayed, ever. A user creates a new blog entry only to find two million FIRST!!! comments. The most popular blog entry based on comments is a 404 Not Found A New user suddenly becomes the most reviled person ever with 200 thousand troll comments ...


5

Since your JSON file never changes, it is an ideal candidate for preprocessing it once, extracting the marker positions, and store them in a file format which is optimized for your specific purpose. You have to solve two different problems here: Create individual sets of markers of different densities for different zoom levels ("level of details")....


5

Cameras don't draw. That is the by and large of it. Photo's are not drawn, and anything compositing a photo into it still has that not a drawing issue. Processing and Bandwidth aren't free A drawn image still has to be rasterised for display on a rastered device such as monitors, and most printers. That requires computation, and many devices are slow/...


4

The backend person might have omitted their valid justifications Back-end person claims that front-end should to have two calls. First to authenticate user (login process) with JWT response only then second to authorize to retrieve user permissions, role(s) and user data. At face value, there's little reason to split a single workload into two network ...


4

You can keep updated data in a memory cache (such as REDIS) on the server side that is flushed into the database less frequently. But the general rule of thumb for optimization is that you don't do it before you: clearly see that there is a performance problem, either by experience or by calculations based on hard data and reasonable assumptions about ...


4

From my understanding, the front end is the UI that the client interacts with, and the back end is the server itself. This is essentially correct. The front end commonly refers to the code that is executed in the user's browser, while the back end is the code that is executed on the server. The first approach is to use React to generate a UI, and then ...


3

MVC was not designed for the web. Its use for the web was popularized by Ruby On Rails. Depending who you ask they are using the term wrong, or they redefined it... yet, it certainly is not what MVC meant in Smalltalk, although a derived concept. Why is that important? Because MVC was being used for desktop application, which did not have a big scary thing ...


3

An application client is essentially anything used by a user. It could be a web page/app, phone app, desktop application, GPS tracker, smart toaster, etc.. An application server would execute server side code for a web application, or any other type of application actually. The application server exists for two main purposes. To abstract and control ...


3

HTTP Status Codes are only designed to tell you about the status of your HTTP transmissions. They have no notion of "business rules." Stick to 200 and 400. When you get a 400, you can retry the request or fail it. When you get a 200, your message is valid; you can then check the returned metadata for status information from your application (i.e. whether ...


3

Paranoid or not depends on how robust your software must be. I think, if your checks have minimal extra implementation costs then they are ok. Example: if you communicate with services through XML the structural verification can be done through an XSD schema. in Java/C# you can have guard statements that throw an exception, if the API contract is broken ...


3

Absolutely. We have been caught out by this with Microsoft APIs, for example, and we were not even set up to log that in our Azure function application. So all we saw was that requests to our endpoints failed. It changed without any warning between hand testing / UAT and actual live use of our application. Our unit tests still worked of course, because they ...


3

Yes, but in most cases that should not be your personal concern. For most languages there are parsers that parse a native JSON (or whatever your transfer language is) response into your internal objects. They come with all the options to consider different writing style, understand corner cases, escape characters, special character encodings etc. Their ...


3

Your validation shouldn't be to restrictive. There is the "tolerant reader" pattern. It means that you should be as tolerant as possible, when consuming data from other services. On the other side, there is the "Magnanimous Writer" pattern. Together, they help to produce more robust communication systems. For example, in a JSON based interface, you ...


3

... how I can build a compiled application interface ... Unlike browser-based applications, executables have to be compiled for (and deployed to and tested on) each target operating system. That's no small job. If you really want to spend the rest of your career fire-fighting the latest Microsoft update that's broken your favourite Windows UI widget, ...


2

4 is good if you have your application begin behind reverse proxy like cloudfront you can configure /api/* to go to your backend. Cloudfront brings other advantages like https and caching. 3 is probably best for your scenario. Just put a step in your pipeline where you transform your index.html (jsdom is good for this) the advantage of using script tags is ...


2

Would you ever ship backoffice admin UI functionality together in the same distribution package as the public client functionality? Maybe, if combining the admin application and the public web application does not incur a huge performance penalty in loading the assets (HTML, JS, CSS, Images, etc). Why I might want to keep them separate: Usually, admin ...


2

Server-side rendering is definitely a good choice. For one of the projects where I was involved SSR was not an option because our SPA framework didn't support it. So we came with a solution which is by no means a design guideline to you but instead is an interesting option you might want to consider. Our project was hidden by a reverse proxy (Nginx). So we'...


2

You will probably do well to review Jim Webber's 2011 talk. Among his early points; HTTP is an application protocol, the application domain is the transfer of documents over a network. Your API is a facade designed to provide the illusion that the HTTP requests are being handled by a "document store" - that's what allows us to leverage all of the general ...


2

For long running tasks, blocking in order to return the response synchronously is not appropriate. What you should do instead is have your service accept the request, start the long running job, and return a success response. Here's a basic design for this kind of thing: The client submits uses POST to send a request that starts the job. You then return ...


2

A web app is an application accessible through the web. One possible way of doing a web app is to have a front end (that's the part that presents the application for use in a web browser, including those parts of web server code that provide HTML pages and assets) and a back end which implements the logical functionality of the application. In your specific ...


2

Generally a push based system doesnt bring subscribers up to date with messages sent prior to the subcribers subscription. If you miss a message, you dont get it. In order to achieve the bring me up todate requirment you can augment the push system with a pull system for history.


2

This is like the classic I/O mistake where you test if a file exists before opening it for writing. By the time you attempt to open it, it may not exist anymore. You test services when you use services. Not before. Testing before use, say to warn the user that the fields they’re about to fill out might be lost is dumb. The services are free to go up or ...


2

What the user assumes the inputs - trial options - are […] Don't allow the user to make such assumptions. With more that a handful of options, the user will guaranteed get some of them wrong. Instead, let the user give each combination of options they want to use a descriptive name before starting a simulation. Then the user can recall that set of options ...


Only top voted, non community-wiki answers of a minimum length are eligible