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

[Removed] Allow Dgraph to be embedded as Go library #673

Closed
manishrjain opened this issue Mar 7, 2017 · 22 comments

Comments

Projects
None yet
@manishrjain
Copy link
Member

commented Mar 7, 2017

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.

@manishrjain manishrjain added this to the v0.8Maybe milestone Mar 7, 2017

@pawanrawal pawanrawal modified the milestones: v0.8, v0.8Maybe Mar 30, 2017

@manishrjain manishrjain self-assigned this Apr 13, 2017

@sebastianmacias

This comment has been minimized.

Copy link

commented May 18, 2017

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

@manishrjain manishrjain assigned tzdybal and unassigned manishrjain Jun 9, 2017

@leedstyh

This comment has been minimized.

Copy link

commented Jun 27, 2017

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

This comment has been minimized.

Copy link

commented Jun 27, 2017

@manishrjain

This comment has been minimized.

Copy link
Member Author

commented Jun 28, 2017

@tzdybal is working on this.

@tzdybal

This comment has been minimized.

Copy link
Contributor

commented Jul 4, 2017

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

This comment has been minimized.

Copy link

commented Jul 4, 2017

  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

This comment has been minimized.

Copy link
Member Author

commented Jul 4, 2017

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

This comment has been minimized.

Copy link

commented Jul 4, 2017

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 manishrjain added the ready label Jul 5, 2017

@manishrjain

This comment has been minimized.

Copy link
Member Author

commented Jul 5, 2017

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

This comment has been minimized.

Copy link

commented Jul 5, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Jul 5, 2017

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

This comment has been minimized.

Copy link

commented Jul 5, 2017

@tzdybal tzdybal added in progress and removed ready labels Jul 6, 2017

tzdybal added a commit that referenced this issue Jul 13, 2017

Refactoring of configuration handling
This is a part of work on #673

@tzdybal tzdybal closed this in 09a4e50 Jul 14, 2017

tzdybal added a commit that referenced this issue Jul 14, 2017

Dgraph embeddable as library
Dgraph can be used as library. It won't open any ports/network
connections. It can be accessed via Dgraph client API.
See contrib/embedded_test to see how to use it.

This resolves #673.

MichaelJCompton added a commit that referenced this issue Jul 16, 2017

MichaelJCompton added a commit that referenced this issue Jul 16, 2017

Dgraph embeddable as library
Dgraph can be used as library. It won't open any ports/network
connections. It can be accessed via Dgraph client API.
See contrib/embedded_test to see how to use it.

This resolves #673.
@ghost

This comment has been minimized.

Copy link

commented Jun 22, 2018

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

@ddibiase

This comment has been minimized.

Copy link

commented Jun 22, 2018

@justinfx

This comment has been minimized.

Copy link

commented Aug 29, 2018

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

This comment has been minimized.

Copy link

commented Aug 29, 2018

any comments from devs?

@manishrjain

This comment has been minimized.

Copy link
Member Author

commented Aug 29, 2018

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.

@manishrjain manishrjain added the wontfix label Aug 29, 2018

@manishrjain manishrjain changed the title Allow Dgraph to be embedded as Go library [Removed] Allow Dgraph to be embedded as Go library Aug 29, 2018

@vtolstov

This comment has been minimized.

Copy link

commented Aug 31, 2018

ok, thanks!

@Wulfheart

This comment has been minimized.

Copy link

commented Jun 6, 2019

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

@martinmr

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

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

@Wulfheart

This comment has been minimized.

Copy link

commented Jun 6, 2019

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

@manishrjain

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.