Allow users to create api end points and then link these endpoints directly to queries/views

Feature Requests
1

for a lot of apps, the web server itself is just a thin layer on top of the db and all business logic is pushed into the db. enabling all these apps to use Fauna as a db as well as a thin server, will mean that I will not need to add a web server to my app at all. I can just have a single backend in Fauna and use a cdn based spa as a frontend.

A basic authorization logic to secure the endpoints will also be required.

eg.

For my server xyz.faunadb.com, i will add an endpoint
/api/posts which is then linked to a posts query. anytime this endpoint is requested, Fauna should return a json containing the output of the query.

We should also support url params, so that a basic query can be crafted in the url itself.

2

Hi @rishavs!

I also personally think that being able to run basically what would be serverless functions close to your fauna data would be super valuable in some cases. Fauna-folks would have to comment on feasibility and priority.

That said, a server is not strictly necessary for what I think you are trying to accomplish. If you’re just getting started, it might not be obvious what all is possible. Here’s some tips, just to scratch the surface.

The simplest way to provide authorization is to use the built-in authentication and authorization abilities, sending a token back to the browser on successful log in.

Using the provided attribute-based access controls (ABAC) is key. I would say the next key thing might be user defined functions.

You might conceptualize any UDFs that a user has access to as the endpoints you are talking about. Rather than send an http post to /api/post/create?title=mypost, you would use the driver of your preferred language to send a query calling the correct UDF. for example,

// javascript in the browser

client.query(
  q.Call(                      // execute a specified UDF
    q.Function('CreatePost'),  // reference to the UDF
    { title: 'mypost' }        // parameters object
  )
)

FQL is powerful enough to allow you to put A LOT of logic into the UDFs. You can add rate limiting, field type validation, perform multiple reads and writes in a single call, all sorts of stuff.

And that’s if the client/user only has permission to use the UDFs you provide. If you provide the user role(s) with permissions to directly read or even write some Collections and Indexes, the client/user can craft any “basic query” desired.

1 Like
3

Thanks for the reply @ptpaterson
I agree that FQl is fairly powerful and can take of the immediate requirements around querying specific functions.

However, I feel the ability to define an endpoint which follows well accepted REST ethos is important as

  1. users have a choice to add an intermediary layer between the client and fauna, like a reverse proxy or a caching layer.
  2. less likelihood of a vendor lockin if the intermediate interface is a well known one like REST apis
  3. i really do not want to use any client side driver as that obfuscates the connection and makes any debugging difficult.
4

Great suggestion. In the meantime I believe the serverless plugin can already make it easier to wire up rest endpoints to serverless functions and fauna functions. GitHub - fauna-labs/serverless-fauna-example: Usage example of the @fauna-labs/serverless-fauna plugin for the Serverless Framework