HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
brillout
wildcard-api
JavaScript2019–2020
brillout / wildcard-api

wildcard-api

Functions as API.

Web Development
Explore on GitHubRead Hacker News discussions
2Distinct people
24Mentions
0Explicit recommenders
369GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Functions as API.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month24 dated mentions

Observed mentions: 2019-08-09 09:57:05 UTC to 2020-12-23 12:55:17 UTC.

02462019-08-01 00:00:00 UTC to 2019-09-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsAug 20192019-09-01 00:00:00 UTC to 2019-10-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-10-01 00:00:00 UTC to 2019-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-11-01 00:00:00 UTC to 2019-12-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2019-12-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2020-02-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2020-02-01 00:00:00 UTC to 2020-03-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2020-03-01 00:00:00 UTC to 2020-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-04-01 00:00:00 UTC to 2020-05-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 commentsApr 20202020-05-01 00:00:00 UTC to 2020-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-06-01 00:00:00 UTC to 2020-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-07-01 00:00:00 UTC to 2020-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-08-01 00:00:00 UTC to 2020-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-09-01 00:00:00 UTC to 2020-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-10-01 00:00:00 UTC to 2020-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-11-01 00:00:00 UTC to 2020-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-12-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsDec 2020

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Aug 20192019-08-01 00:00:00 UTC2019-09-01 00:00:00 UTC202
Sep 20192019-09-01 00:00:00 UTC2019-10-01 00:00:00 UTC303
Oct 20192019-10-01 00:00:00 UTC2019-11-01 00:00:00 UTC000
Nov 20192019-11-01 00:00:00 UTC2019-12-01 00:00:00 UTC615
Dec 20192019-12-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
Jan 20202020-01-01 00:00:00 UTC2020-02-01 00:00:00 UTC211
Feb 20202020-02-01 00:00:00 UTC2020-03-01 00:00:00 UTC404
Mar 20202020-03-01 00:00:00 UTC2020-04-01 00:00:00 UTC000
Apr 20202020-04-01 00:00:00 UTC2020-05-01 00:00:00 UTC312
May 20202020-05-01 00:00:00 UTC2020-06-01 00:00:00 UTC000
Jun 20202020-06-01 00:00:00 UTC2020-07-01 00:00:00 UTC000
Jul 20202020-07-01 00:00:00 UTC2020-08-01 00:00:00 UTC000
Aug 20202020-08-01 00:00:00 UTC2020-09-01 00:00:00 UTC000
Sep 20202020-09-01 00:00:00 UTC2020-10-01 00:00:00 UTC000
Oct 20202020-10-01 00:00:00 UTC2020-11-01 00:00:00 UTC000
Nov 20202020-11-01 00:00:00 UTC2020-12-01 00:00:00 UTC000
Dec 20202020-12-01 00:00:00 UTC2021-01-01 00:00:00 UTC211

What Hacker News says

24 sources
brillout·Dec 23, 2020
Author here. React announced React Server Componets [1] and an interesting feature is the ability to load data without having to create an API. You can already do that today with Wildcard API. I've used it at many projects now and it's quite a pleasure to work with! It feels more natural than REST/GraphQL/Express enpdoints; you simply define and call functions remotely, that's it! I've tried many things to popularize Wildcard but no luck so far. Although it's used at couple of companies so that's quite a success for me already :) Let me know what you think, or if you have any questions regarding APIs in general :-) I'm also working on a couple of neat things such as session management[2], realtime[3], and a new super minimalistic/simple query language[4]. [1]: https://reactjs.org/blog/2020/12/21/data-fetching-with-react... [2]: https://g
Read the rest
ithub.com/reframejs/wildcard-api/issues/59 [3]: https://github.com/reframejs/wildcard-api/issues/61 [4]: https://github.com/reframejs/wildcard-api/issues/60
In Show HN: Wildcard API – Data Loading Like React Server Components, Today
brillout·Apr 18, 2020
> Backwards compatibility and API versioning strategies can easily handle this kind of situation. From experience using Wildcard API (a super easy RPC implementation [1]), you usually don't need to do API versioning at all. Instead you always deploy frontend and backend at the same time. If you have more than one client consuming the API this can get tricky though and then API versioning is necessary. [1]: https://github.com/reframejs/wildcard-api
In SQL is a better API language than GraphQL – Convince me otherwise
brillout·Feb 28, 2020
Do you really need to decouple frontend and backend in the first place? Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend. I'm the author of a Node.js RPC implementation (https://github.com/reframejs/wildcard-api) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.
In Hasura raises $9.9M to simplify GraphQL
brillout·Feb 28, 2020
Instead of Hasura and GraphQL, you can use RPC and directly write SQL queries to retrieve and mutate data. One way to think about this is that with RPC you remove the whole API layer and directly write SQL queries instead, while permissions are defined programmatically on a case-by-case basis. This is much simpler than Hasura! For Node.js there is https://github.com/reframejs/wildcard-api. For other backends you can implement JSON endpoints (https://github.com/reframejs/wildcard-api/blob/master/docs/b...) While scaling to a large company, you progressively migrate from RPC to GraphQL (with or without Hasura).
In Hasura raises $9.9M to simplify GraphQL
brillout·Jan 7, 2020
The most fundamental difference between RPC and REST/GraphQL is that RPC is schemaless whereas a RESTful or GraphQL API has a schema. The whole point of a schema is to have a generic API. Whereas with RPC and any other schemaless approach such as SOAP, you are essentially building a custom API that is only usable for your clients. That's precisely the reason why RPC is not usable to create an API that is meant to be used by third party devS. Third party devS need a generic API. That's the point. Also, a generic API decouples whereas a custom API tightly couples. WSDL is actually only describing the API - it's not defining a schema. So SOAP is not and was never usable for a third-parties. Same for gRPC's proto files. I do appreciate your encouragement but I don't see where I concretely am missing out on something important. You simply stat
Read the rest
e that I'm lacking knowledge without ever concretely showing the flaws of Wildcard. > You are almost close to the enlightenment That's just not very helpful. You are telling me that I'm missing an important point without telling what it is I'm missing. I'd love to be shown wrong. You would for sure save me a lot of effort if you'd pin point my lack of knowledge. For a Node.js backend and a browser frontend, what exactly is the problem with Wildcard API? (https://github.com/reframejs/wildcard-api). As long as you don't have third-parties consuming your API, I'd say that Wildcard is superior to GraphQL and REST >95% of the time. Especially when using Wildcard with TypeScript. > There's always been a pendulum swinging between tightly coupled RPC standards and loosely coupled data interchange standards (or one made from the other in all sorts of combinations). It's a fact of software development life since essentially the dawn of the industry. Interesting. I've not been a programmer long enough to know all that :-). Thanks for you reply, I truly appreciate it.
In REST or GraphQL? A Simple Answer
palberg7·Dec 25, 2019
> services such as https://restdb.io/ or https://fauna.com/ These are a no-go. Why should I use a proprietary solution when there are superior free open source offerings? Sure it's more effort to spin up an aws ec2 instance but that's very well worth it. I then have full control over my database and I don't have to deal with proprietary sh*t. > RPC-named express routes is more than sufficient Yes RPC is exactly what I was looking for. It's super simple. I don't need all that REST and GraphQL stuff. > REST solves Honestly, I don't understand what REST solves. > over-engineering a simple app can lead to greater confusion. Yes simplicity is key. > RPC-named express routes is more than sufficient Actually for Node.js there is Wildcard API[1] which I discovered yesterday. It's even simpler than express routes. [1]: https://github.com/reframej
Read the rest
s/wildcard-api
In Ask HN: Other than REST and GraphQL, what do you guys use?
brillout·Nov 29, 2019
So true. That said, for an API consumed by third-party developers, REST makes a lot of sense. Otherwise, which is like 98% of the APIs out there, RPC really is superior. I've implemented a tool similar to what OP is building: Wildcard API [1] > rather pointless HTTP semantics. Agree. Actually, while implementing Wildcard API, I made sure to abstract away all HTTP semantics. With Wildcard, you don't think in terms of "HTTP verbs" but you think in terms of functions. Like you are naturally used to. > It always baffled me how so-called RESTful APIs became popular I believe REST became popular because it got lot's of exposure since all third-party APIs were using REST. [1]: https://github.com/reframejs/wildcard-api
In Do we need a web API?

Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.