Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How use schema and resource package as standalone #267

Open
opaniagu opened this issue Mar 14, 2020 · 1 comment
Open

How use schema and resource package as standalone #267

opaniagu opened this issue Mar 14, 2020 · 1 comment

Comments

@opaniagu
Copy link

Hi,

I want to use schema and resource package as standalone, have you an example or document?

Thanks

@smyrman
Copy link
Collaborator

smyrman commented Mar 17, 2020

TL;DR: Recommend looking into other libraries such as gorm, upper.io/dbv3 etc.

There is good documentation in the README to help understand the schema package, and how to use it for registering resources into a resource.Index. There is not much documentation on how to do this specifically. The best real-world examples is to see how it's used by the rest sub-packages.

We have been using rest-layer in this way for a while as we have both a REST and an RPC API, as well as internal routines. And to be honest, I will not recommend it unless you have a very strong need to use other parts of rest-layer.

There are some hard challenges to be aware of. Especially when it comes to resource validation, query preparation etc. Again, the best examples here is the code in the rest package.

Some of our main challenges, by priority:

  1. Type safety: Type safety is very big challenge in in rest-layer because everything is a map[string]interface{}. While very dynamic, it's a lot of verbose and error prone type-casting involved when writing any kind of logic that operates on these objects, including resource hooks.
  2. Payload preparation & validation: The preparation of a "raw" payload into something that can be sent to the DB involves a complex division into something called base and changes before you can insert it into the DB. Similarly, the prepare step for queries is easy to forget.
  3. Non-thread-safe schemas: The ways fields and schemas are generally defined, is by pointers that may provide a "compile" step. Because of this, if reusing a field definition in multiple schemas, it's not safe to Compile those schemas concurrently.

There are many good alternatives for abstracting resources in Go. Such as gorm, upper.io/db.v3, or maybe https://github.com/facebookincubator/ent. I recommend good resarch to find which one fits your needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants