I'm new - I'm baffled - help with customer facing approach appreciated

Highlighted
Shopify Partner
12 0 6

Hello,

I am new to Shopify (non-plus) and after 2 days of reading the developer documentation I’m still no closer to understanding some of the basics – in fact I have read so much yet understand so little.

I am familiar with OAuth and javascript front end programming.

 

I'm really excited to get going developing apps - I'm revving the engine but literally no idea which way to go before I spend time travelling there.

 

What I am trying to achieve

  1. A standard shop (I have my own products to sell) - easy part - no problems here.
  2. A ticket booking section (20 places OR 18 places + wheelchair)

I want the visitor to be able to visit a page/product page and select from a calendar with specific dates, choose a date with tickets available, then select quantity, verify the tickets available with a remote service, clear cart + add to cart and immediately proceed to checkout (without the ability for them to modify quantities other than the screen I provide).

 

The challenge

An event takes 20 people max.  Unless there is a wheelchair visitor – this would take two places.  There can only be one wheelchair at an event (this will change in the future but for the sakes of describing the challenge let’s say 1). 

I have added 20 standing tickets and 1 wheelchair ticket as products (though maybe I could add products on the fly as I provide them dynamically - open to alternative ways).

I have to check if the event already has the maximum number of wheelchair tickets purchased i.e. 1.
I have to check if the total standing tickets have not exceeded 18 (because one wheelchair takes 2 places).
I have to check if a wheelchair ticket cannot be purchased if there are already 19/20 standing tickets purchased.
If 18 tickets are purchased and then one wheelchair ticket, the standing tickets will need to be reduced by 1.  I’ll worry about cancellations later on.
I would ideally like to query a remote service to confirm ticket availability.

 

Current plan

Setup a StoreFront API to offer a separate (from the main shop but still on the same Shopify shop) purchase experience which provides calendar to checkout experience.

 

Main question

Would this be the best/correct/recommended way to proceed?
Is there other way to achieve this from a customer perspective or browsing, selecting and ordering one or more tickets?

Bridge App cannot be used for public areas yet?  Any idea when I can use this simple JS approach for everything as I believe it uses OAuth for better security?

Note: I will use Bridge App to build the management / POS side of things so currently not worried about this part.

 

Bonus question 1 – StoreFront API and basic security

StoreFront API is confusing me. It says it is an unauthenticated public API.
One of the permissions is “Read and modify customers” – does this mean if someone got a hold of my public key they can read the personal data of customers i.e. name and address??
Another permission is “Read and modify checkout” – does this mean other people’s checkout/baskets can be changed?
With the message “You should use Storefront API if you are comfortable with this risk” – I don’t know what risks to which the help documentation is referring to – what part is risky?  What part will cause me potential issues?  Sounds scary and really not sure if it should be avoided but I don’t know what else to use instead.  Is there any alternative to StoreFront API that would be safe and secure i.e. that uses OAuth?

 

Bonus question 2 – Private app – basic security

Private apps use urls containing the key and secret.  If this is transmitted over the network on a public page – does this mean you are exposing the password if I were to use Chrome Developer tools? – again I must be misunderstanding something because it does not sound secure for my customer data (should my app decide to interact with that data).

 

Bonus question 3 – can’t see the wood for the trees

With so many APIs and ways to achieve things, I’m wondering if there is a way to reduce my confusion – which of all these tools are to be depreciated (e.g. Application Proxies) and I should not spend time on or vice verse – which are the new ones that would achieve what I’m trying to do?

 

I appreciate any assistance that can be given – I’m sure it will all click into place and I’ll have a moment of true understanding but require some help interpreting the documentation in the meantime.

Many, many thanks.

Dan.

2 Likes
Highlighted
Shopify Partner
1840 177 711

Hello Dan,

 

Bonus Q1

It means anybody who gets hold of your token can query the store data which would be quite easy if you have the token in some client side Javascript. But that's how all such public APIs work. However, that does not mean anybody can read or change the customer data because if you look to the query or mutation documentation for that object or mutation, you will find it requires a customerAccessToken which is provided when the customer logs in (see customerAccessTokenCreate).

 

Bonus Q2

Private and public apps run on servers and make use of the Shopify Admin APIs which do require a key and password but those are ONLY held on your servers running your app. Note, this within Shopify means an app only you and your store use, or an app you have published publicly and can be used by other stores i.e. not to be confused with public app a la a store website. Basically, you'd never ever expose that key / password say on a client side Javascript or via a URL - yes you can technically, but by golly that'd be your own fault.

 

Bonus Q3

It's quite simple really once you get the hang of it - which as you said will happen in time. Here's the lo-down:

  1. Storefront API is unauthenticated and used to query store data, perform "safe" mutations which would be done on a website anyway (create cart, add items, register customer, fetch product etc.). It is a newish API and it is GraphQL as opposed to REST.
    • Storefront API can be used as is - it is GraphQL after all so you can use it as is or with your preferred GraphQL client for a favourite language, framework or even a Shopify specific client.
    • Mobile Buy SDK is one such wrapper of the Storefront API for Android platform (Android Buy SDK) and iOS (iOS Buy SDK).
    • Unity SDK is another such wrapper of the Storefront API for the Unity 3D game engine API i.e. to allow in game purchases and other creative usages
    • JS Buy SDK is... well I am sure you guessed by now, a Javascript wrapper of the Storefront API that you can use in your website or even Node.js on the server.
  2. REST Admin API is the backend API used by apps (whether public ones that have been / haven't been published in the Shopify App Store, or private apps that are store specific). The API has a lot of endpoints that are sometimes confusingly grouped in to further SDKs or APIs, but I'd recommend you simply ignore that and follow the REST endpoints. Now, for public apps, you would need to use some endpoints that are commonly known as the EASDK (embedded app) or POSSDK (for POS terminals) and have now been superseded by newer App Bridge. But you only need worry about those if you're creating a POS or want to in some way publicly offer your app to other merchants.
  3. GraphQL Admin API is like the REST Admin API albeit in GraphQL, is still hot off the press, has some benefits over the REST one, still catching up to the REST one and will be the future for sure, but isn't there yet. If you're writing an app and starting greenfield, use it but expect to fall back to REST API as well.
  4. Shopify Ajax API is yet again a client side API for those nifty little drawer carts and such gimmicks that add clobber to your basket without you leaving the page. It's XHR based and has been and still is used VERY widely. Storefront API might be the new kid on the block but for now I'd guess 99/100 themes and stores use this tried and tested API on the client.
  5. Proxy apps are a mechanism that allows 3rd party content or data to be provided directly in to your theme i.e. Liquid for instance so that you can directly incorporate it there. That's all it is. You'd still need that 3rd party service though which mostly is your app.

As for your main question... hang on a minute, you had like a dozen questions in there!

 

Either way, I tried to clear the forest a little. Recommendations aren't really my forte (politically correct way of telling you I don't do them for free for the scope you'd require 😀)

 

Best wishes and enjoy your Shopify journey!

Liked this post? You might also like our fantastic upsell apps Candy Rack and Candy Cart or offer free gifts with Gift Box. All made with ❤️  and care by Digismoothie
5 Likes
Highlighted
Shopify Partner
12 0 6

Well you have certainly cleared a few trees for me! Thank you very much for fantastic reply!

 

I made a start with a StoreFront API app - went really well thanks to the Angular Shopify sample - does what I need - but I do now need to do some lookups on on the database i.e. lookup orders (ensure no other wheelchair orders and <=18 places taken / amend products (reduce quantity of spaces because wheelchair takes two).

 

Questions - Can I make REST calls to my own hosted service which would then in turn make another OAuth REST calls to Shopify that would have access and rights to inspect/amend products/orders?  Would this cause cross server issues calling a rest service from another domain?

Can the same be achieved with an embedded app as I only need this experience in a Shopify page somewhere.

 

I created a more focused question at the following if you wish to answer the question there.

https://community.shopify.com/c/Shopify-APIs-SDKs/Building-a-custom-cart-Storefront-API-Vs-Embedded-...

 

Many thanks,

Dan.

0 Likes
Highlighted
Shopify Partner
78 3 7

I know this is from earlier this year, but I just wanted to let you know that I am in 100% agreement with you. The Shopify documentation is terrible. It took me almost 3 months of consistent reading and nearly 10x re-reading the documentation, posts, tutorials, etc. to even being to feel like I knew what was going.

 

Now that I'm functionally familiar with the whole platform, I've gotta say, I could re-write the documentation in a way that the normal Joe would be able to have the understanding I currently have in less than a week's time of study.

 

Shopify is a powerful platform, but the documentation is horrendously confusing, misleading, inconsistent, and vague.

 

Why they didn't just say "This is how it all works, this is how you do it!" instead of "4446ng Wokke 54324  --{}--3=234j1 ,,,,, whp shopify urjo34354ter..."; I'll never know.

Most people, it turns out, just aren't interested unless they have to pay for it. Go figure.
0 Likes