[erlang-questions] [ANN] GraphQL Erlang 0.8.0

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Wed May 24 15:08:45 CEST 2017

Hi Son,

You can create a safe hybrid solution in GraphQL which uses atoms, and it
is one of the changes we are considering. The parser will produce
binary/string data since it is in the control of the client and we can't
trust the client. But in the elaboration step, we can run
list_to_existing_atom/1 and binary_to_existing_atom/1. If we don't happen
to have that atom we know the query is structurally invalid and we can just
reject it. If it is structurally valid, we can safely convert into atoms
and use them. GraphQL is a statically typed system and we can use this fact
to handle it safely.

The reason we are considering the change is that it would be more idiomatic
than the current solution. One particular strong point is that the dialyzer
is able to describe maps in which the domain is given by atoms. But it
can't describe maps in which the domain are binaries.

The reason we use binaries right now is that it was the easy solution. The
system does allow atom-use in the 'enum' types for now, but we plan on
folding enum handling into a solution which is more akin to scalar
handling. This moves the flexibility onto the developer and we don't have
to add code to the graphql system whenever people want a new encoding of
enums. GraphQL is a fairly big system and mapping it onto the Erlang world
took some trial and error. Some of the trials turned out to be less
optimal. But one also has to put a foot down at some point and get
something out rather than keeping to optimize for elegance.

Now, having said all that: if you just blindly convert client-side-data
into atoms, you can easily get into trouble with clients: either
maliciously or innocently, and this is a choice that should be rejected IMO.

On Wed, May 24, 2017 at 4:23 AM Son Tran-Nguyen <son@REDACTED> wrote:

> Hi Jesper,
> I just want to say thank you for open source this. You can't imagine how
> grateful I am to read that the library use binary for keys. Other
> implementations in Elixir use atoms everywhere. With server that can take a
> dynamic schema from users, using atoms is just bound to fill Erlang's atom
> table.
> Again, thank you. I'm looking forward to using this.
> On Mon, May 22, 2017 at 9:26 AM, Jesper Louis Andersen <
> jesper.louis.andersen@REDACTED> wrote:
>> Hi,
>> I'm happy to announce that ShopGun's GraphQL code is now open source:
>> https://github.com/shopgun/graphql-erlang
>> GraphQL (http://graphql.org) is a query language for the web which is an
>> alternative to RESTful web services. There are some similarity to Joe's UBF
>> stack as well, though it is a completely different take. Originally from
>> Facebook, we implement a GraphQL engine which is almost fully featured in
>> Erlang.
>> I have a talk at the Erlang Users Conference 2017 on this project, but we
>> are releasing the system early since we are far enough in its lifetime to
>> do so, and there is little reason to keep it closed anymore. If you are
>> interested in this project, please come see the talk :)
>> Because GraphQL is a fairly large system, there is an accompanying
>> tutorial to the project, which uses the graphql backend:
>> https://github.com/shopgun/graphql-erlang-tutorial
>> and it has a quite complete tutorial book written as well (pending some
>> sections which is still being written)
>> https://shopgun.github.io/graphql-erlang-tutorial/
>> It is our hope that the tutorial will help people use the repository and
>> build some great software on top of it.
>> As always, comments are welcome. Either in this thread or in Issues in
>> the projects if need be. PRs are also accepted and we want to encourage an
>> open development strategy on the system. While the project probably still
>> has some rough edges, we expect to grind them down over the coming months.
>> Happy Hacking on behalf of the ShopGun team :)
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170524/63af3ae0/attachment.htm>

More information about the erlang-questions mailing list