[Removed] Allow Dgraph to be embedded as Go library

[manishrjain]

Lot of people are trying to use Dgraph as an embedded library in their Go code. This should be feasible once we move away from Cgo.

[sebastianmacias]

+1 this is the only reason that currently keeps me from switching from cayley this is how you use cayley as a library.

[leedstyh]

Any progress on this?

If this will not be ready in the near future, can we move app's main logic into a package. This way make it easier to custom build, like building all the services including dgraph into one binary.

FYI, this is how caddy server does

[mikelnrd]

Thank you! Spark by Readdle

[manishrjain]

@tzdybal is working on this.

[tzdybal]

I have some questions to all users interested in embeddable version of Dgraph:

1. Our vision of Dgraph embedded as library is following: client code calls database engine directly, there are no network connections, no servers listening for connections, no access to UI. Application can use the database through client API.

2. Because of the tight integration with the core database engine, we need to publish the embedded version of a Dgraph under AGPL v3 licence. Will this work for you?

[sebastianmacias]

1. That's exactly how I envision it. It will give the users the ability to deploy golang web applications using a single binary; not having network round trips to get and put the data will result in speed/performance gains.

2. AGPL v3 sounds fine. As long as the developers don't modify Dgraph's embedded library AGPLv3's Section 13 won't trigger so the source code of the full web application isn't required to be made available. Is that correct?

[manishrjain]

As per AGPL v3 terms, anything which embeds AGPL code would also be covered by AGPL, and hence, you'll have to open source your full web application under AGPL. So, it's not ideal.

We could provide special (non-AGPL) license to users who intend to use this for non-commercial purposes, or are small startups; but still, it isn't as direct as using Dgraph as a server.

[runningwild]

I'd been banking on embedding DGraph, so this is sad news. I can't possibly embed it if I must do so under the AGPL, and having only now realized that the server is under the AGPL I'm hesitant using DGraph at all (I was aware of the Apache license, which I liked).

Do you have any idea what kind of commercial licensing you will offer? If I can't use DGraph under a less draconian license I will be forced back to using Cayley.

[manishrjain]

You can use the server under AGPL without affecting anything. The client libraries or calling Dgraph via http endpoint is all under Apache 2.0 license. This licensing system is in-sync with what MongoDB does. You can read our blog post regarding this change.

With the embeddable version, we can of course, give you a commercial license to avoid AGPL, this would just let you run Dgraph's open source version without affecting the rest of your code base. There would be some pricing involved (probably free for individual projects / small startups though).

If this sounds like something you guys can live with, we can build the embeddable version of Dgraph client. If it seems like something you absolutely don't want, then no point building it. You can always use Dgraph with the client-server architecture.

FWIW, I don't think embeddable Cayley would give you any better performance if it's talking to another DB running as a server.

[sebastianmacias]

I guess it would depend on how the comercial licensing would look like. A per seat/developer/team type of licensing would work in my case, a licence per domain/server wouldn't.

[manishrjain]

The actual licensing details can be worked out. Just wanted to ensure that the embeddable version is still something that would be of interest to folks. We'll work on it.

[erichiller]

I'd be interested in an embeddable library for sure, and your functionality description sounds great. The AGPL license is worrying as others have said, particularly because in my case I was planning on using it in a client side application, so a per instance fee would be prohibitive compared to a server-based architecture.

…

On Jul 5, 2017 8:54 AM, "Manish R Jain" ***@***.***> wrote: The actual licensing details can be worked out. Just wanted to ensure that the embeddable version is still something that would be of interest to folks. We'll work on it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#673 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFIU_SELvle0c4fw1aFwfyLNH1Jw8csTks5sKzMbgaJpZM4MWDTX> .

[ghost]

This was tagged as a feature and I also really wanted it. Any idea if this functionality was added though ??

[davedbase]

I agree, would be really great having it as a Go library.

…

On Fri, Jun 22, 2018 at 2:18 PM gedw99 ***@***.***> wrote: This was tagged as a feature and I also really wanted it. Any idea if this functionality was added though ?? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#673 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHUDVTfsUY7tg-KyjVznZIPFFGGGZlWks5t_TUAgaJpZM4MWDTX> .

-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

[justinfx]

Where did this work move to and what is the current status of the embedded support? I must be overlooking something but the merged support last year isn't showing up.

[vtolstov]

any comments from devs?

[manishrjain]

This feature was removed because it was proving hard to maintain with all the distributed work that was going on, particularly after Zero (membership and transactions) was separated off from Alpha (data storage) servers. This won't be brought back.

[vtolstov]

ok, thanks!

[Wulfheart]

This is really sad. Is there any way to use it in a offline application?

[martinmr]

you can run Dgraph in a single machine. Just run one instance of zero and an instance of alpha in the same machine.

[Wulfheart]

I want it for a simple application. So this shouldn't be feasible, is it?

[manishrjain]

With docker compose, everything is just one docker-compose up away. So, it's definitely feasible. Unless you're trying to avoid containers.

[vzool]

+1 this is the only reason that currently keeps me from switching from cayley this is how you use cayley as a library.

+1 I hope to see embedding Dgraph as a library as well regardless of the agreement type.

With docker compose, everything is just one docker-compose up away. So, it's definitely feasible. Unless you're trying to avoid containers.

-1 I hate to use another Go application(like docker) to run my Go application, I think this is a waste of a limited resources. Any Go application is weaponized with the same tool-set that docker use. So, What's a point to repeating myself again with different label!

[RyouZhang]

+1 I hope to see embedding Dgraph as a library as well regardless of the agreement type.

[marcown]

would be nice to use it embedded and really helpful

[maurerbot]

🙏