Cannot read property 'DgraphClientStub' of undefined

This is probably not a bug, but more likely a lack of knowledge on my part.

I’m trying to use Dgraph-js-http with Sveltekit (SvelteKit v1.0.0-next.114).

I have the following javascript, to create a store:

import {writable} from "svelte/store";

export const resume_store = writable([]);

import {dgraph} from 'dgraph-js-http';
// import grpc from 'grpc';

// const dgraph = require("dgraph-js");
// const grpc = require("grpc");

const clientStub = new dgraph.DgraphClientStub(
    // addr: optional, default: "http://localhost:8080"
    "http://localhost:8080",
    // legacyApi: optional, default: false. Set to true when connecting to Dgraph v1.0.x
    false,
);
const dgraphClient = new dgraph.DgraphClient(clientStub);
...
//create query etc

Error

However, when I run npm run dev I get the following error:

11:31:07 am [vite] Error when evaluating SSR module /stores/resume.js:
TypeError: Cannot read property 'DgraphClientStub' of undefined
    at /stores/resume.js:11:31
    at instantiateModule (/home/anton/git/resume-web/node_modules/vite/dist/node/chunks/dep-cb562f8f.js:68783:166)
Cannot read property 'DgraphClientStub' of undefined
TypeError: Cannot read property 'DgraphClientStub' of undefined
    at /stores/resume.js:11:31
    at instantiateModule (/home/anton/git/resume-web/node_modules/vite/dist/node/chunks/dep-cb562f8f.js:68783:166)

What Dgraph client (and version) are you using?

(put “x” in the box to select)

  • Dgo
  • PyDgraph
  • Dgraph4J
  • Dgraph-js
  • Dgraph-js-http
  • Dgraph.NET

Version: 21.3.1

Update

I was able to move past the above error by using the following:

import * as dgraph from 'dgraph-js-http';

Now the error I’m facing is:

500

Buffer2 is undefined

node_modules/safe-buffer/index.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:554:9
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
node_modules/jws/lib/sign-stream.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:1126:19
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
node_modules/jws/index.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:1306:22
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
node_modules/jsonwebtoken/decode.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:1339:15
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
node_modules/jsonwebtoken/index.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:3396:15
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
node_modules/dgraph-js-http/lib/clientStub.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:3598:15
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
node_modules/dgraph-js-http/lib/index.js@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:4587:18
__require@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:7:44
@http://localhost:3000/node_modules/.vite/dgraph-js-http.js?v=43e3f0da:4595:30

Is it a front + backend framework? I wouldn’t recommend to use Dgraph at frontend tho. Always put your DB behind an API. Never expose it in the front-end without a safe manner. These errors happen when the framework isn’t supported. NodeJS logic is always supported tho.

Thanks @MichelDiz

This is a frontend framework.

I understand your point however the primary reason I’m using dgraph is because I can avoid the usual layers, eg, database, dao, business logic, public api etc.

Also, in this particular case, the usage of the application is internal and trusted.

So, you can use the RAW HTTP requests(Via Axios, fetch and so on). It is much more simple. In order for us to support the framework you are using, it will require time to analyze what is missing and what can be done. In other words, it will take time. JS support for Dgraph is preferably “framework-less”.

Ok, thanks I’ll try using fetch.

Regarding your previous point. If you recommend “Always put your DB behind an API” why is the dgraph graphql api not sufficient to be exposed publicly? And can you recommend any simply and good graphql proxy apis?

No, you can expose the GraphQL API for sure. Just add the auth feature and you are good to go. Is the DQL part that isn’t safe to expose.

Excellent. This is very good to know.

Can you expand on this a little please.
Is there are Dql endpoint and a separate Graphql endpoint?
And is the dql endpoint more sensitive?

Yes. There is /graphql and for DQL /query and /mutate and /commit.

Yes, it is open. And DQL you have a much powerful query to modify the DB or mess up with things.

DQL is for pros who will handle the DB by hand.
GraphQL is for casual and frontend users who doesn’t wanna bother with implementation in the back-end. As the GraphQL feature is practically autonomous. It generate your CRUD schema out of the blue for you.

Oh no. Now I’m facing an identity crisis. I’m using dql but am no pro!

Thank you again @MichelDiz - your guidance is excellent!

lol

pros be like lollll

Kidding, that just a way of saying it. You can be a pro too, just protect your DB :stuck_out_tongue: