Is there any way to prevent graph.cool from alphab...
# prisma-whats-new
d
Is there any way to prevent graph.cool from alphabetically organizing my fields? Each type's field would be a lot more humanly legible if they were organized in the order in which I created them:

http://i.imgur.com/bunafYv.png

So apparently by design 🙂
🎯 1
d
good eye!
😄 1
@agartha btw, this is prob premature, but regarding security, are there any benefits to having
Billing
(which contains billing info) be it's own type (as shown in my schema above) ?
a
Depends on your permission queries
You can specify fields in your read permission queries too
d
I haven't looked into permission queries yet. I suppose I should get on that now
a
You can exclude fields from your read permission, so it doesn't have to be another type for that reason
Although it's a list in your schema
So then you will need a different type
Do be aware that you are legally not allowed to store CC details...
Unless anyone from Graphcool can tell you they comply with all regulations for that. @sorenbs?
n
When using a service like Stripe they take care of all those regulations. Instead, you work with a token that authorizes one-time access to the Stripe API for that credit card.
About the ordering of fields, have a look here @dk0r https://github.com/graphcool/feature-requests/issues/15
d
great point, @agartha. Thanks nilan --I'll start searching the graphcool git for now on
@nilan, in the link above you say
This could be elegantly solved by using the order in the project's schema file
and then link to https://www.graph.cool/docs/reference/cli/project-files-ow2yei7mew/
I don't see anything about
order
on that ^ page. I found the link below, but it's only related to queries, not the actual schema order: https://www.graph.cool/docs/reference/simple-api/ordering-by-field-vequoog7hu/
@agartha since you bring up regulations, are we similarly regulated by what type of data we can store on under-age (aka minors, aka <18 years old in the USA) users?
a
The schema file (the one shown in the schema view), is leading for specifying the order of fields, and all other views follow suit. That's what the FR is about
🤔 1
👍 1
@dk0r I could go on for hours on legal matters, the lawyer charges me €600,- an hour to make sure I comply with all of them 😄
d
oh wow
a
No, seriously, that's a discipline of it's own
It depends where the server is located for most data
For some data, based on where the user is located
Mobile apps have their own rules set out by MS, 🍏 and Google
Same goes for encryption.
You are legally not allowed to export data that is encrypted using certain algorithms from the US, that includes replication between US and EU servers
because the algorithm is on the US Munitions List
💣 1
A leftover thing from the cold war era
Seriously, you don't want to get into finding this kind of stuff out for yourself. Ask your business partners for their compliancy, buy a second passport, and hope for the best 😄
d
interesting --thanks for all this. I'm still in the mvp stage of my app and not worried about liability (yet). I guess I'll need to keep all this in mind as I make design decisions...
a
Like @nilan said, let companies like Stripe deal with credit card data
The only thing I do pay attention to myself, is the geographical region of anyone that stores or uses my data
d
And what implications do you determine based upon their location?
That is, how do you determine those implications? Only via legal consultancy ?
a
Before I launch a product, I have them do a legal audit, that's about it. 9 out of 10 times it's fortunately the problem of my client/customer, because most of what I do is for clients.
d
I see. I'll start looking for general guidance to make sure that during the mvp stage I don't end up becoming dependent upon data that will inevitably get yanked --appreciate all the advice
a
yw, also consider hiring a penetration testing agency, especially since a lot of technologies and libraries are pretty bleeding-edge, there's a lot of reinvent the wheel going on in your own hooks and sss later on probably, so that never hurts 🙂
d
thanks --I'll prob bug you for a reference once I'm at that stage 🙂
a
Sure