Videos
Hi all! I recently created a golang api (a server that gives json when accessing specific api routes)
The problem is that I don't know how to make a frontend for it? A lot of people recommend htmx but it requires you to give html instead of json, I don't want to change my server. What other ways do we have to create a frontend? Learning react is a very difficult task, it looks huge, need something faster
but what?
Not sure if this is the best place to ask, I've been out of the front end world for a while, but I know there are a ton of frameworks in the space these days. I have an API that I'd like to expose via a very simple UI. Is there a framework that's built for for this use case? Like, bare minimum stuff here. If I have an endpoint that returns json, I want a page that will simply executes that endpoint (with parameters) and then loops over the resulting json spitting out something decent looking. And if makes sense for the user to be able to click into one of the items listed, a way to link to a page with a parameter that would do the same. Something that's like a half step fancier than Swagger?
I feel really silly for describing it this way, and maybe the answer is just a basic/popular web framework for the language of my choice, but also maybe something like this exists? 😂 Thanks!
I think you're being confused by the way the term API is being misused and abused by many web developers.
- API means Application Programming Interface, i.e. any officially specified interface between different systems (or parts of the same system).
- Some time ago, it became a big thing for web startup to offer public access to some of their internal data through a web service API, typically using REST and JSON, thus allowing third-party developers to integrate with their systems. Web developers started using the term "API" to mean specifically (and only) "publically accessible web service", and misusing it to include the implementation thereof.
- In terms of frontend and backend, this web service API (and its implementation) is the backend. Some parts of it may be publically accessible and others only to your frontend.
- A different name for this is "service layer", i.e. code that
- represents services which the frontend calls
- contains no display logic (that's the job of the frontend, after all)
- is more abstract and coarse grained than simple CRUD actions (one service call will often involve multiple CRUD actions and should be executed within a database transaction).
- contains the business logic of the application
Let us sketch out a "typical" website's architecture, with both a "front-end" and a "back-end". And since it's a website, we'll also explicitly have a "client". (Since there's no way for JavaScript in a browser to call MySQL on a server directly.)
For clarity, the terms we're using are:
- Client: The HTML5 compliant browser, esp. the DOM and the JavaScript there loaded to manipulate it.
- Front-End: The PHP server that the DOM is pointed to, containing both the individual page requested and some AJAX style XML or JSON access points.
- Back-end: A database server, where MySQL runs.
For a properly designed program, each of these components has a private API to communicate with the others. The "front-end" PHP code does not issue arbitrary SQL SELECT statements directly, but rather calls stored procedures, pre-authorized SQL, or even distinct PHP calls to an entirely different instance of PHP that runs on the back-end server. These stored procedures or distinct HTTP calls are themselves an API.
The definition doesn't change even if we allow for some impurity of our design. If your PHP file writes and sends a SQL string directly to MySQL, IT IS STILL AN API, albeit a very unusual one that you are unlikely to repeat.
Note that it's entirely possible to have your front-end PHP be strictly synchronous, with no AJAX voodoo whatsoever. If you call the same external PHP functions in said synchronous file, you could consider them as using the same API as the client-side version, although use of the term "API" here may not give any real clarity.
An API as an Application Programming Interface, after all, and really refers to any time one program calls outside of its own process. If you're writing a project that has both a front-end and a back-end, be those AJAX/PHP/MySQL as above or MS Access/SQL Server, it's worthwhile to specify explicity how you'll be calling each other, if for no other reason than to make it easy to know where to look when something breaks.
(And the topic of public API is something else entirely. In our example above, only the URL displayed in the client is a "public API." Everything else is, in essence, "private." As in, you don't expect any code beyond your control to call your internal API, and you either deny such results outright or reserve the right to do so in the future.
Yo frontend devs, how do y'all usually work with backend teams? Do they just hand you APIs and say 'go build,' or do you have to request specific endpoints? Also, do you ever get a peek at the database, or do you just trust whatever the backend team gives you?