API vs Full App

off.the.walls

Hey everyone,

Wanted to start some discussion around this as i've noticed a trend in recent years of moving away from building apps with a dedicated backend to building apps with an api at the backend and a front-end that simply accesses data through that api.

I can see the benefits of this it would make things a lot easier in terms of building a phone app, web app, tablet app all separately and having them make requests to the api to power them all.

What's everyones opinions on this are API's the way to go forward in the industry or is it simply a matter of coding preference.

Speedwell

No, as an IT professional approaching 50 whose boss is a developer/coder, who is involved with several platforms, and who just got back from the Salesforce Tour conference in London, I'm backing the "APIs are the future" horse with all I've got. It is comparable to the time when you had to speak compiler to write a program, and then people came out with programming languages. Or, if you're a little younger, it's comparable to the time when you had to design graphics by coding the base shapes in a text language, and then someone invented WYSIWIG, or when you had to write documents with a cheat sheet stuck above your keyboard so you could remember the command codes. APIs are going to be the new standard because they automate so much stuff that is time-wasting wheel-reinvention now.

Graham

off.the.walls wrote: »

i've noticed a trend in recent years of moving away from building apps with a dedicated backend to building apps with an api at the backend and a front-end that simply accesses data through that api.

You still have a dedicated backend, the only difference is it's accessed via an API rather than the front-end/back-end being intertwined.

Unless you're developing a particularly small project I can't think of many valid reasons not to develop a separate backend accessible via an API. I can think of plenty of reasons why you should.

A singular interface for multiple front-ends, e.g. web/mobile/TV/AI assistants
A single interface to run tests against.
An interface for external vendors/systems.
A single interface to secure.
The ability to upgrade/replace and front-end systems without touching the back-end.
An interface based around de-facto industry standards (REST/JSON) almost completely
The (almost) complete elimination of any requirement for expensive middleware.
The ability to choose additional tools based on their features/functionality rather than being restricted to what's compatible with your current back-end.
The end (or significant reduction) of data-silos.
Standard documentation.
Automation of production of documentation.

14ned

off.the.walls wrote: »

What's everyones opinions on this are API's the way to go forward in the industry or is it simply a matter of coding preference.

This is really a very ancient theme.

There is a long established process that as some collection of design patterns becomes accepted as less worse compared to others, it gets standardised into an OS or a library or some other collection of APIs.

It's no different for your use case. The newer and more bleeding edge your niche field is, the more bespoke and custom its software is. The more mature and widely accepted it becomes, the more standardised implementations of common components turn up. Eventually something becomes so entrenched everybody has to be compatible with it, else nobody will touch your solution.

A good example is Plan 9 which was a reboot of Unix by the founders of Unix themselves. Plan 9 was and is great and is superior to Unix in many ways.

But it wasn't compatible enough with Unix, so it was shunned. Later they greatly improved Unix idiomatic compatibility, but by then the ship had sailed.

Another good example is Windows NT, whose kernel is actually a freshened edition of VAX VMS's kernel, and is so much superior to DOS Windows it doesn't compare. But everything was compatible with Windows, so they had to shoehorn in a compatibility layer to emulate a Windows environment on top of a real operating system. That got shipped as Windows NT, and it's still the same design in Windows 10 where all your Windows software is actually running inside a Windows emulator. Because computers are so much faster nowadays, you don't notice the hideous inefficiencies of that emulation layer day to day. For example the kernel has zero problem with a directory containing 10m files, but god help you if you try typing 'dir' on that directory from within the Win32 emulation layer.

Apple OS X is also similar. It's really a FreeBSD kernel emulating a Mach kernel so its NeXT software ecosystem can pretend it's on an original NeXT box back in the early 90s. I slightly exaggerate, but I'm not wrong either, if you poke around the low level innards of OS X you'll see plenty of barely touched near original NeXT code.

The point is it isn't really about whether APIs are the future. They always are for any widely adopted successful software design pattern.

Niall

Labarbapostiza

Speedwell wrote: »

APIs are going to be the new standard because they automate so much stuff that is time-wasting wheel-reinvention now.

As Ned14 has pointed out, APIs were/always will be, the old standard, the new standard, simply the standard.

Wheel reinventors will always find a way to reinvent the wheel.

A high level language essentially provides an API to lower level or system APIs. The high concept being code would be as simple to write as having conversation with another human being, and companies could fire all their nerds and replace them with people who have social skills. The concept is deeply flawed on so many levels, considering how twisted and dysfunctional human relations and human conversation, and that is among the people with the supposed social skills, can be.

SUN's Java, which promised to raise the dead and heal the sick, was a wrapper on the C language, which is in itself a wrapper on an API that speaks to the APIs of the operating system, which is a wrapper to the mechanics of the machine. The reason for JAVA's popularity was really programmers adopting it, to stay employable, because prospective employers had swallowed the salvation gospel spewed by the Java evangelists. Architecture evangelists are typically upper-middle-class American males, who give TED type talks of utter gibberish, but that sounding meaningful to the kind of people who do the hiring and firing.

As a kid I learned to code in C on MS Dos. The experience was heart breaking. The standard libraries, from Borland, didn't behave as predicted. As a young person, I was yet to become aware of how cruel the adult world could be, and just barely, ever so barely but don't breath on it, functioning was a good enough shipping standard. I had to build my own graphics API of magic tricks, to get the Borland graphics API to work without crashing. Did my API work better than Borland's; when you build on a foundation of crude, how good can your construction be. If I had a better understanding of MS Dos, and how it functioned, how to figure out how it works, it would have taken me less time to write a graphics API from scratch than it did for me to create a layer to get Borland's API working.

This is a downside of APIs. The guy writing them, doesn't have to use them. They may barely function. A true story; a company I worked for bought a hardware device for use in their product, because it was promised it came with an API and support from the company. After literally months of badgering the company for documentation of the API, the guy sent a document. A small text file, that when you clicked on it opened up to display a single line "this is the document for the API". I have a better understanding of the world now. The device we bought, most likely was created by another company, and resold then, and probably resold again, any original documentation for the API lost along the way, relabelling of the code by code "gurus" further obscuring its' origin. And the "guru" we were dealing with didn't have a clue anyhow, and probably spent most of his day preparing TED style talks evangelising some new crude on crude as the salvation of the human race.

The Window's system directories are very interesting (haven't looked at 10's yet). You will find lots of surprising things in there if you take the time. There are files that only apply for use in 16-bit dos. Microsoft may have tight control over their kernel and essential core elements, but for a lot of other software they've developed, they've built on top of the 16 bit code base. There is a lot interesting stuff in the system directories, but Microsoft don't even seem to have the documentation for much of it. I've found things in there that have given me moments of "If only I had known this was there, my life would have been so much easier all those years".

If the "gurus" are pushing APIs as the next "thing", it's very like the "cloud" and "cloud" computing. If you look at telecoms technical documents from at least the early 70s, those that have rare graphics the cloud was a common shorthand hand. Do "gurus" make anyone's life better. When the "cloud" fad started, programmers were heard to remark; "We're doing cloud computing now?.....WTF were we doing all these years?". Or one I heard; "Narrowband?..Broadband?.....I've been coding for network and telcoms since the 70s...WTF are you on about?"

Aswerty

Wait, wait, wait..

1. Are we talking about APIs in general?
2. Or are we talking about monolithic architectures vs service architectures?
3. Or are we talking about monolithic architectures vs micro-service architectures?

We already have two discussions on the go (1 and 3), and I'm not even sure if either of them are what the OP is asking after (which I think is 2).

Graham

Aswerty wrote: »

Wait, wait, wait..

1. Are we talking about APIs in general?
2. Or are we talking about monolithic architectures vs service architectures?
3. Or are we talking about monolithic architectures vs micro-service architectures?

We already have two discussions on the go (1 and 3), and I'm not even sure if either of them are what the OP is asking after (which I think is 2).

I think the OP is referring to web apps, admittedly an assumption on my part but one that's based on OPs previous posts.

Aswerty

Graham wrote: »

I think the OP is referring to web apps, admittedly an assumption on my part but one that's based on OPs previous posts.

That's the impression I got but half the posts don't seem to be about that

And even if it's about web apps; there's a significant distinction between micro services and just decoupling the back-end and front end. The OP doesn't mention micro services but that's about the trendiest thing in this space at the moment. Fat/Thin client architectures have been about since forever and they'd arguably fit the OPs question but I wouldn't exactly call them trendy.

Graham

Aswerty wrote: »

even if it's about web apps; there's a significant distinction between micro services and just decoupling the back-end and front end. The OP doesn't mention micro services but that's about the trendiest thing in this space at the moment.

I think this part of the OP is the relevant bit

off.the.walls wrote: »

in terms of building a phone app, web app, tablet app all separately and having them make requests to the api

counterpointaud

Labarbapostiza wrote: »

...

And the "guru" we were dealing with didn't have a clue anyhow, and probably spent most of his day preparing TED style talks evangelising some new crude on crude as the salvation of the human race.

...

Well, you may have wandered off topic somewhat, but thanks for the entertaining post

Giblet

Well, what I see now is hundreds of API calls on a single device, meaning it's actually slower.

React Relay, Falcor and other dispatchers are the future I think, and we'll see more optimization around that space.

Also HTTP2 will improve things a lot.

Ideally, the backend is setup in such a way that APIs are effectively wrappers to what you have been calling anyway.

14ned

Aswerty wrote: »

That's the impression I got but half the posts don't seem to be about that

And even if it's about web apps; there's a significant distinction between micro services and just decoupling the back-end and front end. The OP doesn't mention micro services but that's about the trendiest thing in this space at the moment. Fat/Thin client architectures have been about since forever and they'd arguably fit the OPs question but I wouldn't exactly call them trendy.

I'm probably really about to show my age now ... but "micro (web) services" used to be called microkernel OS kernels in the 1980s, in the 1990s they were called Distributed Component Object Model (DCOM) and I actually can't think of their name in the 2000s. You could run a microkernel OS over a distributed network of machines connected by a network without issue, indeed QNX - the last remaining commercial microkernel OS - is still developed internally by all the kernel developers running on a distributed single OS instance.

Point is, every single decade some fashion du jour pops up of making software into lots of small single purpose services which you tie together using some form of duplex IPC channel. Whether they are called pipes, sockets or whatever isn't particularly important.

I used to serve on the IPSCC for Ireland and one of the older members considered the web as merely the logical continuation of the networked mainframes of the 1960s, and he's absolutely right. You think JSON was in any way an innovation over XML? Nah, just another reinvention of the same wheel. Englebart's 1968 demo of the semantic web structured data similarly to SGML which became XML. There was, like with XML, a reaction against that in favour of a simpler markup.

Almost always every innovation you think computer science does is really a reinvention of the wheel. Almost everything "new" today was first conceived, and often implemented, in the 1950s and 1960s. It's actually much more scary how little we've innovated in recent decades, we just retred the same old ground with "new" solutions.

Niall

mightyreds

Hi guys sorry to bring this back up again but I'm thinking of making an open source project that will consist of the API and allow anyone who wants to use it create their own front end.

This is a first for me to try this, I'm trying to find out how I'd use the API would it be a series of Ajax calls from say as an example jquery for get and post.

So for example on login post the data if susscessful redirect, if not display the error.

Then on editing data would I send the get request and fill the form on load, then post the data on submitting.

Or really any tips or input is appreciated

bpmurray

mightyreds wrote: »

Hi guys sorry to bring this back up again but I'm thinking of making an open source project that will consist of the API and allow anyone who wants to use it create their own front end.

This is a first for me to try this, I'm trying to find out how I'd use the API would it be a series of Ajax calls from say as an example jquery for get and post.

So for example on login post the data if susscessful redirect, if not display the error.

Then on editing data would I send the get request and fill the form on load, then post the data on submitting.

Or really any tips or input is appreciated

The API should return whatever data is requested, or an error code. It should never do anything like trying to handle the error. Don't assume that it'll be JavaScript - it could well be a completely unexpected source, so make sure that you religiously follow the rules for POST, GET, PUT, DELETE = Create, Read, Update, Delete (CRUD), although some APIs use POST always to ensure that any data is in the headers rather than in the URL. In particular if you can't guarantee idempotency for GET, make sure you document that clearly.

I've found that you can make your API more attractive by providing a very thin layer of JavaScript to make it easier to use, so that developers can add whatever JS framework they want, whether it's JQuery, React, Angular, etc. very easily without thinking of the API's nuances. For example we produced a Dojo UI for one product and also created another JQuery UI, while both leveraged the thin JS layer which hid the complexities of the Comet-like long poll.

mightyreds

Sorry yeah I wasnt clear there I meant handle errors on the front-end as I'm gonna try build a front-end myself and use the API, but I was thinking of using HTML and jquery as that's what I know the best , just trying to get my head around how it'll work.

I've made an API in a college project before but it only returned Json would it be wrong to do it this way?

deconduo

mightyreds wrote: »

Sorry yeah I wasnt clear there I meant handle errors on the front-end as I'm gonna try build a front-end myself and use the API, but I was thinking of using HTML and jquery as that's what I know the best , just trying to get my head around how it'll work.

I've made an API in a college project before but it only returned Json would it be wrong to do it this way?

I'd recommend taking a look at http://swagger.io/ - quite a nice standard for REST APIs.

bpmurray

deconduo wrote: »

I'd recommend taking a look at http://swagger.io/ - quite a nice standard for REST APIs.

Swagger has moved to be the Open Api Initiiative - here's an interesting interview about the whole OpenAPI thing with lots of stuff relevant to creating your own API. OP, if you follow their ideas, you'll create a pretty solid consumable API.