Hey guys,
there's this idea stuck with me for a real long time.
Imagine you build a small webapp and you don't care about how your API-Endpoint for database queries would look like. So urls like "endpoint-0", "endpoint-1", etc. aren't a dealbreaker. You could just let a compiler generate the api for you!
Before I get into the details I want to explain, how apis are commonly build:
Server API-Endpoint
- create a function that handles the database query
- gather the parameters from the request
- serialize the result
- think about a good url (optional: store the url into a definition file -> for easier refactoring)
Client-Request
- create a second function that makes the api call
- pass all needed information in a correct way to the endpoint
- deserialize the response
- then return it
Pseudocode
What if you'd just write one function and the serialization and api-call part would happen automated?
You'd just write:
// Server side code // generates intern api-endpoint // function body will be replaced with an api-call to that endpoint async function getPost(id) { return db.first("SELECT * FROM Post WHERE id=?", id); } // ... // Client side code (can import the auto generated getPost(...) function) console.log(await getPost(1)); It looks very clean and easy to understand.
Downsides
But: you also don't know exactly what happens under the hood, it's harder to think about authentication, authorization, etc.
And that's actually why I would call this a bad practice... Nevertheless I like this idea very much :D
Prototype:
Because I don't have the knowledge to make a plugin for a bundler like vite oder webpack, I thought I'd give it a try with Rust.
Here is a working protype:
#[macro_use] extern crate rocket; use rocket::{Build, launch, Rocket}; use serde::{Serialize, Deserialize}; use serde_json; #[derive(Serialize, Deserialize, Debug)] struct Data { pub foo: String } // proc-macro would be much nicer! (but I'm too lazy :D) ssf!{ "/api/foo", // api-endpoint for foo(...) foo_route, // reference to the endpoint so we can mount it later on // the following function body will be replaced with an http-call async fn foo(text: String) -> Data { Data { foo: text } } } #[get("/test")] async fn test() -> String { let data = foo("bar".to_string()).await; // does a http request to /api/foo with data { text: "bar".to_string() } serde_json::to_string(&data).unwrap() // Response is '{ "foo": "bar" }' } #[launch] fn rocket() -> Rocket<Build> { rocket::build().mount("/", routes![foo_route, test]) } And here you've got the macro:
macro_rules! ssf { ($path:literal, $apiname:ident, $(vis:vis)? async fn $fn:ident ( $($name:ident : $type:ty),* ) -> $ret:ty $body:block ) => { // Params #[derive(Serialize, Deserialize)] struct Params { $(pub $name: $type),* } // The actual function (wont be accessable from the outside due to hygiene) fn serverside($($name:$type),*) -> $ret $body // Endpoint #[post($path, data="<body>")] fn $apiname(body: String) -> String { let data: Params = serde_json::from_str(&body).unwrap(); let result = serverside($(data.$name),*); let response = serde_json::to_string(&result).unwrap(); response } // HTTP-Request async fn $fn($($name:$type),*) -> $ret { let client = reqwest::Client::new(); let params = Params { $($name),* }; let response = client .post(format!("http://localhost:8000{}", $path)) .body(serde_json::to_string(¶ms).unwrap()) .send().await .unwrap(); let mut body = response.text().await.unwrap(); let data: $ret = serde_json::from_str(&body).unwrap(); data } }; } Be aware that you will need to check/modify the hardcoded url in the macro to make it work on your machine!
I would love to hear your opinion on this :)
Have a nice day!
Top comments (1)
Of course you are right that boilerplate code should be abstracted away and not reinvented over and over...
There are many libraries/frameworks that help automating the wiring.
If you're in the RESTful world, there's OpenAPI standard and its vast ecosystem that allows you to easily build a server. Checkout openapi.tools
There's Google Protobuf, although less popular, also has its own ecosystem, and there are more.