I don't want to work on my project this weekend, so I can work on yours.
1
Hi Kishore,
I would like some tips on how best to technically approach this idea, both an MVP approach, and a more extensive approach.
I would like to build a restaurant seating management UI, essentially having tables and seats set up per the physical restaurant layout, but done virtually. Additionally I'd like to be able to mark a seat/table as available or occupied, and for how long (time remaining).
The way this would work is I myself would build the "virtual restaurant" UI myself (I don't know how, your help here please) individually maybe using HTML canvas, or build my own "builder" (worthwhile?) to make the process more repeatable. And finally allow the restaurant to embed (code snippet) the visualization on their restaurant business site. The restaurant staff would be managing the available/occupied status via a secure account.
What's the most MVP way to achieve this - layout builder, embeddable interactive layout, update status via login.
Thanks for your time and generosity
1
This is how I will approach this kind of application.
Technology Stack
Firebase or AWS as backend, NodeJs. For login and registration I suggest using Firebase login but I wouldn’t recommend Firebase client database API, instead I would go with Firebase Functions for all server processing (Another advantage is later if you decide to go with DigitalOcean or other VPN you can easily migrate to NodeJs/Express Function.) For me RDBMS is the quickest way to build MVP but with Firebase you can only use NoSQL DB.
ClientSide tech: I don’t recommend directly using Canvas. You can create your own layout component with ReactJS but providing customization is hard and bug prone. Instead go with something like frabricjs (http://fabricjs.com/demos/). With FabricJS you can easily create predefined layouts and let restaurant owners pick from them or quickly make new ones as needed.(You can also create an SVG layout and import into FabricJS).
I used Fabricjs for Watermark.ink (with Angularjs) and it saved a ton of time in visual component placement and arrangements. There are wrappers for AngularJS and ReactJS. I suggest you go with React, it’s a much cleaner code, easy to maintain and extended.
Allowing the restaurants to embed code snippets is a bad idea. Not because of security but because of import conflicts and code errors. It is very difficult to limit or control that kind of code snippets. Instead give them an easy to drag-and-drop layout maker made with fabricjs.
Let me know if you want anything more.
1
Thanks for the feedback, Kishore. Much appreciated.
I have some follow-up comments and questions (alot).
Now I am unfamiliar with Firebase and it's full capabilities so will need to do more research on it. From a cursory search, Firebase is a paid service?
You mentioned AWS as an alternative to Firebase, and seeing how Firebase does not support a RDBMS, AWS would make sense then. Are there particular services I'll need from AWS that I should be mindful of?
I can concur with you about not pursing the canvas approach. Having only watched a couple introductory tutorials on canvas, it doesn't look to scaleable, in the sense of quickly reusing floorplan components - like a table, or chair image - to recreate a new floorplans for new restaurants, quickly. There's likely a way to speed this up using canvas, programatically, but I don't know it. And from my minimal knowledge of canvas as this point, the way I could conceive, would appear like reinventing the wheel over and over. Tedious and not scaleable.
With said, I will need to look into FabricJS. I had not heard of it until you mentioned it. And I definitely be more inclined to having custom layouts versus a set of predefined layouts, restaurants could choose from.
Correct me if I'm wrong, but by SVG layout and importing in FabricJS, do you mean using a drawing software like Illustrator to draw the floorplan, save as SVG, and import into JS? If I want to change the appearance of say a table or chair based on a change in status, will this still work? Or will the SVG remain static, and I'll need overlay a visual treatment for status changes?
And on the topic of embed code snippets, what I was thinking of was a once a floorplan has been designed and configured, programmatically generate a code snippet, that the restaurant can copy/paste into their site. From this approach, would there still be code errors? And what exactly are import issues?
Ideally, a drag-and-drop floorplan builder would be ideal. A restaurant to log in, use the builder to build their floorplan, generate a snippet, and embed the snippet in their website to render the floorplan. Or are you saying, they have the actual builder on their site?
As I would like to be able to aggregate and track the patterns and actions of availability changes for all client restaurants, I figured the embed approach, would allow me to track those changes via the embedded floorplan. Essentially a floorplan widget. A restaurant owner/staff logins into my service, updates a status, status is reflected on their website, and wherever they have the floorplan widget embedded. Does this make sense?
Lastly, aside from FabricJS, can this be done with vanilla JS or is a framework required - Angular, Node, React etc.? As you can see, I'm new to this.
Thanks, again much appreciated
1
Now I am unfamiliar with Firebase and it's full capabilities so will need to do more research on it. From a cursory search, Firebase is a paid service?
Firebase has 3 versions - Free, Fixed($25) and Blaze(pay as you use). https://firebase.google.com/pricing/ If you want to have a payment system like stripe you have to choose paid version. If you are new to server setup, security etc I suggest you go with Firebase(only learning curve is NoSQL DB), using NoSQL is easy, but designing storage structure in a proper way is a pain. For simple applications you don’t need to worry about pricing. Blaze (pay as you go will only ask for your creditcard, it wont charge until you exceed the free limits.
You mentioned AWS as an alternative to Firebase, and seeing how Firebase does not support a RDBMS, AWS would make sense then. Are there particular services I'll need from AWS that I should be mindful of?
You can check AWS RDS https://aws.amazon.com/rds/ You need to check with their pricing. You can also look at Microsoft Azure. If you looking for a cheaper option consider VPN like DigitalOcean Droplet (starting with $5 per month).
--
For MVPs and minimal users the price chart goes like this (I am not sure about the AWS/Azure limited free tier. I only used paid AWS and Azure)
Minimal User Price: Firebase(Free) --- DigitalOcean(or other VPN) --- Azure --- AWS
As the number of users reach to hundreds of thousands the price chart looks like
Millions of Users: DigitalOcean --- Azure --- AWS -------------------------Firebase
(Firebase is expensive once your user-base grows to millions). Once you gain millions of users I only see Azure or AWS as a viable option. Among AWS and Azure I felt Azure is the easiest to deal with AWS (pricing, setup, configuration gets super complicated after a level).
----------------------
I can concur with you about not pursing the canvas approach…..
You will save alot of time and frustration if you go with a Framework instead of building everything from scratch. (If your UIcomponent is simple, using Canvas directly maybe a better option). I have only used FabricJS (extensively for Watermark.ink ). I suggest you also look at https://konvajs.github.io/
----------------------
Correct me if I'm wrong, but by SVG layout and importing in FabricJS, do you mean using a drawing software like Illustrator to draw the floorplan, save as SVG, and import into JS? If I want to change the appearance of say a table or chair based on a change in status, will this still work? Or will the SVG remain static, and I'll need overlay a visual treatment for status changes?
You can save your FabricJS Object(UI visual part) and export it as json or SVG. Then you can load those files(json or svg) into FabricJS. You can create a SVG file and import into FabricJS. I encountered some glitches while importing SVGs created with illustrator but for most of my needs it worked fine.
About Editing/appearance based on status: Yes you can do that but its tricky. As the underlying object is SVG you can change the color and few properties of those object. According to what I understood from your description I think that is not what you need. Changing the appearance of the SVG is not a right design. I suggest you one of the below two designs.
Have two different table objects(SVGs reserved-table-RED-svg and unreserved-table-GREEN-svg) one for unreserved and one for reserved and manipulate them based on the status.
Dynamic object
Create a SVG with non-modifiable UI (using illustrator etc) and import it into Scene(UI)
Create another top component (like RED, GREEN based on status)
Group these two components and use it as a single table object which changes display based on status.
I observed that layering two or more components (SVGs + other) works flawlessly than editing the imported SVG properties.
----------------------
And on the topic of embed code snippets, what I was thinking of was a once a floorplan has been designed and configured, programmatically generate a code snippet, that the restaurant can copy/paste into their site. From this approach, would there still be code errors? And what exactly are import issues?
I think I misunderstood your question before. What I understood now is, you want the Restaurant owners to design their tables layout on your site and then embed that tables layout into their restaurant website. Am I right?
For this you need to create an iFrame which restaurant owners will copy (from your site) and paste(embed) into their website. This will work fine, no issue here.
Ideally, a drag-and-drop floorplan builder would be ideal. A restaurant to log in, use the builder to build their floorplan, generate a snippet, and embed the snippet in their website to render the floorplan. Or are you saying, they have the actual builder on their site?
As I would like to be able to aggregate and track the patterns and actions of availability changes for all client restaurants, I figured the embed approach, would allow me to track those changes via the embedded floorplan. Essentially a floorplan widget. A restaurant owner/staff logins into my service, updates a status, status is reflected on their website, and wherever they have the floorplan widget embedded. Does this make sense?
I might have misunderstood your previous description. I thought it in the following scenario
Restaurant owners(owner) register and login into your site.
Design(build) their floorplan using a layout builder with custom visual components example:-
Layout builder asks questions like how many tables ? how many chairs per table? Table color? etc...
Owner will drags and drops table on the layout and save it.
Owner get the iFrame code to paste it into their own website.
Restaurant user will visit the Restaurant site, select a table and timing, etc
Are end users( Restaurant users) not allowed to reserve a table directly? Are the restaurant owners website is only to display the reserved tables but not for reserving?
------------------------
Lastly, aside from FabricJS, can this be done with vanilla JS or is a framework required - Angular, Node, React etc.? As you can see, I'm new to this.
There are two things here,
1- Developing a complete web app like user login, UI components etc: with vanilla JS is asking for future problems. Extending with new features, bug fixes, cross browser issues, etc are difficult with vanilla JS. Pure ValinallJS is suggested only for simple websites, yours is an application, you need to consider things like adding additional features, bug fixes, code maintenance, cross browser compatibility etc. (I am planning to write an article about frameworks, I will share it with you.)
The top 3 popular web frameworks I know are ReactJS, VueJS, AngularJS. Note: ReactJS takes time to master.
2- FloorPlan builder: Doing it with pure Canvas is error prone. With FabricJS or KonvaJS you will save development time, have tested and predictable behaviour.
1
Thanks again for your detailed response, Kishore.
It definitely helped clear things up. Alot of my original plans or ideas of the product and design/code/deploy strategy are based on my limited understanding from reading, and not so much doing.
__
Firebase, thanks for the explanation on what Firebase does, and the pricing structure. And per you point about setup and security, I have no experience with security, and being particular about ensuring security and user privacy, I'd like to be sure I can lock things down. In regards to that, what does Firebase offer/do to cover the security aspect?
I do expect to implement payments, subscription based and tiered. And from what I can see, Stripe is well regarded, but haven't looked much into alternatives. But it sounds like, with the paid Firebase plan, Stripe integration will be painless.
In regards to NoSQL, I haven't worked with NoSQL, but if it needs to be done, I can live with that. In regards to this restaurant app, is the data I'm working with or potentially collecting (restaurant metrics, date time etc) suitable for a NoSQL approach or is it a nonissue? I ask because I've read that certain content-types are better suited to NoSQL databases, versus a traditional RDBMS. Will launching with a NoSQL database, introduce migration issues should I want or need to switch to RDBMS in the future?
__
AWS/DigitalOcean
This is interesting to see a mention of a VPN. Just to confirm, you aren't speaking of a VPS (virtual private server, step up from shared served tier), since I've briefly used one with HostGator, and it turned out to be overkill for what I needed. If you mean VPN as virtual private network, then I am confused. I've never come across VPNs discussed with hosting discussions, so I apologize if I'm mistaken.
I guess I assumed that the go-to for hosting nowadays was cloud-pay-as-you-need. And for that matter was looking into the AWS free tier, but from your Firebase discussion, AWS free does not compete with offerings of Firebase free. It looks like Firebase, by design, is turn-key for an app whereas AWS is a lot of bolting services together.
Millions of users? Nah, very unlikely. But should that be a problem, I will or someone will have already foreseen and planned a hosting strategy (a good problem to have). But it's good to know that Firebase can be affordable for small and medium sized user bases.
__
Fabric/Konva/SVG
I will have to look into Konva too. My main area of confusion is understanding why they exist, or the primary problem they were designed to solve, but from your explanation it's coming clearer. The JS world is huge, and a lot of libraries and frameworks exist for niche solutions.
In regards to the SVG discussion, I think I follow you. Rather than dynamically changing the visual treatment of the SVG (limited control on what you can visually change), instead create multiple versions of the object for each possible status/variation, and just toggle their visibility/activity based on the status, correct? Like if status=A, set objecttype=objectB, else set objecttype=objectA.
__
Embedding/Floorplan builder
Correct. A restaurant would use my site to create a floorplan for themselves after which they can embed into their business site.
Depending on the finalized user flow and UX, the floorplan design process could start with a series of user questions, which then help guide the options available in the builder. Good point.
I personally would like to, for the MVP, be able to allow restaurants to use drag-drop builder, a self-service DIY approach. But if it's too complicated, for me at least, would there be an alternative to quickly do the floorplans myself using input from the restaurant, without a drag-drop builder UI (not scaleable, but doable on the shorter term), that isn't too tedious and inefficient.
Eventually, yes, I would like to expand features beyond just restaurant owners/staff but also customers. Including a reservation process. With that said, does that add much more complication beyond the approaches already discussed?
Again my limited understanding comes into play here, as I had thought iframes were deprecated and frowned upon nowadays, so it sounds like I'm mistaken on that too. Sounds like iframes is the right embed method. Are there other alternatives out of curiosity?
I will read that CORS article. Thanks for the reference.
__
Frameworks
That makes sense. As I am looking to be as time efficient and future proof as possible, I figured that with JS frameworks, new frameworks become vogue every couple years. And it becomes a job learning and keeping up with frameworks. Would vanilla JS in that sense be more future proof as it will have less dependencies and lower risk of deprecations?
I guess my mentality is build once, do minimal maintenance, and not have to constantly be needing to transition and rewrite things. Unless that is just a necessary evil of creating a secure, functioning app nowadays?
I am investigating the possiblity of making this a PWA, progressive web app, to get better mobile and offline UX and performance. This product doesn't sound complex or specialized enough to jusify an investment in a native app at this stage. Does this completely change what's been discussed/proposed?
I look forward to your framework article!
__
Thanks, I'm learning alot from you!
1
--- Firebase security:
With "serverless" solutions like Firebase. There is no server to manage (Google will manage,maintaine those servers, you just write your application code).Security, crash recovery, load balancing(for large applications) etc are all provided by Google.
Other alternative popular Serverless solutions are Microsoft Azure Functions, Amazon Lambda and Google Cloud Functions(this is different from Google Firebase).
--- NoSQL:
For your application it is not difficult to implement with NoSQL. If you are not aware of NoSQL it will take more time to think/understand in NoSQL style.
I don't like NoSQL DB's, but one small advantage is less code to write.
NoSQL DB is not a one-to-one data migration to RDBMS. The Nonsense of NoSQL is there is no data normalization, you duplicate everything. If you decide to start with NoSQL I suggest you don't giveup after few hickups like normalization issue, having Firebase manage your DB and letting you worry about code is a huge advantage for MVP.
--- AWS/DigitalOcean:
Very sorry to confuse you, I mean VPS (Virtual Private Server) not VPN.
AWS pricing is super confusing and some features look like workaround solutions. I am very happy using Microsoft Azure.
--- Fabric/Konva/SVG:
Why they exist?
Imagine you are buiding an application like Online Photo Watermarking tool. If you try to implement drag and drop, resize,scale, rotate feature(bug free) that will easily take over a month. With FabricJS I am able to do it in few days. You can visit Watermark.ink the underlying draw area component is FabricJS.
instead create multiple versions of the object for each possible status/variation, and just toggle their visibility/activity based on the status, correct? Like if status=A, set objecttype=objectB, else set objecttype=objectA.
Yes exactly, you can toggle and display what is needed. That is also easy to implement and modify. You can easily build a complex layers example:
But if it's too complicated, for me at least, would there be an alternative to quickly do the floorplans myself using input from the restaurant, without a drag-drop builder UI
Visual Drag & Drop builders are complex, but making a simple floorPlan builder doesn't sound complex for me. I have to think about it.
I would like to expand features beyond just restaurant owners/staff but also customers. Including a reservation process. With that said, does that add much more complication beyond the approaches already discussed?
I believe the most complex and attractive part of your application is visual floorplan builder and visual reservation UI. While designing the floorplan-visual-component you have to keep a note that some of the floorplan features are also going to be visible, editable(in future) for customers. Design it like baseFloorComponent and extend features in floorBuilderComponent and floorDisplayComponent. Otherwise you have to redesign and implement the customer facing parts separately.
as I had thought iframes were deprecated and frowned upon nowadays, so it sounds like I'm mistaken on that too. Sounds like iframes is the right embed method. Are there other alternatives out of curiosity?
iFrames are limited in features and styling so not a recommend approach. iFrames are still useful for some usecases, google still uses iframes for google forms.
I don't recommend vanilla JS, you will spend more time in bug fixing(like cross browser issues), reinventing things, etc.
I guess my mentality is build once, do minimal maintenance, and not have to constantly be needing to transition and rewrite things. Unless that is just a necessary evil of creating a secure, functioning app nowadays?
For application like yours once you build it and it is working fine you don't need to worry about converting into newer framework. Unfortunately now-a-days who ever disagree will create a new framework. But there is a specific problem these frameworks are concentrating to solve. For simple applications any framework is better than vanilla JS. ReactJS is over kill for some applications, there is a steep learning curve(it is different from traditional web apps) and if you need to learn React Redux then you can dedicate a month for just understand it. I believe Redux is a complex solution for simplifying things :)
If you are not familiar with ReactJS go with AngularJS or Vue. Your FloorPlan component will greatly simplify if you use React kind of component approach, thats why I recommend it. Also you can use React and other frameworks together, just be-careful with data sharing across them.
I am investigating the possiblity of making this a PWA, progressive web app, to get better mobile and offline UX and performance. This product doesn't sound complex or specialized enough to jusify an investment in a native app at this stage. Does this completely change what's been discussed/proposed?
If you develop in React you can share some part of the code while making a mobile application.
Ah, that makes sense. I always thought AWS was synonymous with what you're describing as "serverless" but it's not. Is "serverless" synonymous with a turn-key app hosting solution or can you be serverless but manage it yourself?
Is AWS Lambda Amazon's competitor for Firebase? And Microsoft Azure is MS' Firebase competitor? Does DigitalOcean offer a similar service.
What made you decide to go with Microsoft Azure?
--
Database
Does Firebase offer more than the others - price, service, support - to warrant having to use NoSQL? I'm a little wary about going with Firebase/NoSQL out of convenience per se of having it managed by Google. Maybe I'm just old-fashioned and don't want "all my eggs in one basket" and feel "safer" with an RDBMS.
If I'm not mistaken from my reading on DB architectures, NoSQL are more performant at the cost of redundancy.
Having an ability to move my data around, is just comforting, but perhaps I'm overthinking it, especially per this particular product where it's really user data, restaurant data, floorplan/layout, and usage/reservation data.
Do AWS Lambda, Azure etc. also require a NoSQL database? Is NoSQL just required for "serverless" solutions?
--
VPS
No problem at all. Thanks for clarifying. So Virtual Private Server hosting still exists in this world with all the buzz about AWS, pay-as-you-go hosting offerings?
--
Fabric/Konva/Watermarking/SVG
I see! When you referenced your watermarking service, I wasn't sure what I was looking at. Specifically, which parts of it was powered by Fabric/Konva. So it looks like the majority of it, and some of the capabilities your application has, also shares my needs, and can be done with Fabric.
What's the difference between Fabric and Konva? Why did you choose to go with Fabric?
Previously we discussed using SVG as a method to get the floorplan out and embeddable. After looking around Fabric a bit, it looks like with drag-drop UI, after you've created the desired layout, you can export the layout as an SVG. Correct?
But if we are incorporating those different layers, for the different statuses, how does one manipulate the visibility of those layers, after it's been exported? I assume the layout is done using one layer/status, but when it goes "live" are the other layers triggered on the SVG itself? Sorry if this is confusing, I'm just trying to visualize.
Also, is it possible to establish a grid or a snap-to-grid capability on the drag-drop UI? For a floorplan, have some form of grid or dimensions helps with layout-spacing consistency and UX. Having said grid, once positioned in the canvas, can the locations/coordinates of each element be "saved" and then used to recreate the layout elsewhere (like the iframe embed)?
--
Floorplan builder
Having done some mulling, just going straight for the builder UI seems like the more time efficient way to do it.
With that said, seeing how there will need be user accounts - restaurant owner/staff and customers, and then god-mode (me), there needs to be some way to control who can do what, ie. different versions of the builder per se:
God-mode - I could build a floorplan using the builder on the behalf of a less-technically-capable restaurant. As well as any admin tasks
The restaurant owner, logs into my site, in their account, builds a floorplan on the builder, and exports the SVG/iframe to embed in their site. Additionally, could track metrics on occupancy etc - ex. which table is most popular and when. Even track customers for marketing outreach etc.
Restaurant staff, has a staff level account, associated to the owner, and have capabilities to reset, update, statuses of table occupancy and reservations. they would log into my site and be able to manipulate the floorplan, but not build/change layout. Layout is set by owner, but staff can interact with elements. Any of these changes would be reflected on the embedded widget on the restaurant business site.
Customers, would have an account, and access any restaurant's floorplan, but is limited to reservation placement and cancellation tasks. Their changes/updates are reflected on the specific restaurant's site.
Having written this out, it feels like there's a public floorplan embedded on the restaurant site which shows statuses in real-time, but interaction is done either through my site directly (via restaurant subpage) or if the customer is already logged in to my site (cookies?), can interact directly with floorplan on the restaurant site (the interaction-mode just changes - read-only to active).
Am I still only requiring one builder, but different views or SVGs to embed or be accessible, based on the user type?
--
Embed/iframe
One thing that is quite critical is to control who can embed what in their website. As in, the restaurant owner should only be able to embed it, on their website, and that the embed code can't be stolen from inspect-source and embedded elsewhere. It would not be good if a competitor restaurant could embed another's floorplan in their site, for whatever reason, malicious or not.
Can iframe embedding be made secure and trackable (who embedded it where)?
--
Frameworks/ReactJS
Thanks for pointing out that in most cases I could pick the most suitable framework - looks like React - and not have to worry about keeping up with the framework Joneses. It's quite a relief.
Honestly I was quite turned off by not using vanilla JS out of concern of using an outdated framework and constantly playing catch up. It looks like in my case, that's a nonissue.
Thanks for that.
I will need to read more on React, but at least I have a direction.
--
Thanks again, Kishore
1
can you be serverless but manage it yourself?
Letting companies like Google/Firebase/Azure/Amazon manage the server is called Serverless. If you want to manage it yourself, you can do it with your own VPS.
Is AWS Lambda Amazon's competitor for Firebase? And Microsoft Azure is MS' Firebase competitor? Does DigitalOcean offer a similar service.
Yes they are all competitors. I felt firebase is the quickest to start among them.
What made you decide to go with Microsoft Azure?
We as a group decided Azure(not me alone) because most of our applications are Windows based. But later started using Azure for our Linux systems too. I felt Azure is much nicer and cleaner than using AWS. Some of the AWS features are a mess, especially pricing.
And I am not sure about the performance side of NoSQL vs RDBMS. I read some of the NoSQL DB's are designed for better writes than RDBMS.
Do AWS Lambda, Azure etc. also require a NoSQL database? Is NoSQL just required for "serverless" solutions?
With Firebase there is not option for RDBMS, but with Google Cloud you can still use RDBMS Database.
Even though Firebase and Google Cloud are from Google they operate little differently and concentrate on different users. Firebase was an independent company which was primarily concentrating and providing mobile applications backend systems, data storage, analytics etc. Google acquired them and continued that as a separate service to Google Cloud. Some of the Google Cloud and Firebase inter-operate.
AWS, Azure, Google Cloud, DigitalOcean are all Virtual Private Servers. Except DigitalOcean others provide more features like Serverless, Functions, Lambda, etc.
--
Majority of what you see in Watermark.ink is FabricJS Canvas.
FabricJS ...you can export the layout as an SVG. Correct?
Yes you can export as SVG or as JSON object
But if we are incorporating those different layers, for the different statuses, how does one manipulate the visibility of those layers, after it's been exported?
You should create a custom component and use exported layers inside the component. The rendering/visibility code is inside your custom component.
Also, is it possible to establish a grid or a snap-to-grid capability
Am I still only requiring one builder, but different views or SVGs to embed or be accessible, based on the user type?
The design sounds good, but I can't answer without knowing complete features. Also it is not completely possible to have one builder which is extended on top of the previous user(access level). There are situations where some features maybe specific which doesn't need to be inherited, in such situations you may need a Composition(design pattern) kind of design.
--
Can iframe embedding be made secure and trackable (who embedded it where)?
Others can't tweak iframe code, if there is a dynamic code in it, it simply doesn't work. With clever tricks like server handshake you can also restrict displaying it on pre-registered domains only. For domains which are not authorized you can restrict.
--Frameworks/ReactJS
React takes some time to learn. VanillaJS is very difficult to manage and extend large applications. Your applications I believe is a bit complex, if I were you I will surely avoid vanillaJS. Have a look at Typescript.
Some of Robin tutorials are good, the following link provides a detailed How-to for developing Firebase-Authentication-React App.
Thanks for clarifying. I will continue reading up on Firebase, and then potentially Azure/AWS should my product's userbase grows to a point where Firebase is economically unfeasible.
At this stage, the data I have in mind that will be saved/queried should be okay with NoSQL, at least, I don't foresee big issues with duplication. Thus making Firebase a viable option.
Also, thanks for clarifying what serverless means, meaning managed versus self-managed.
__
Watermark/FabricJS/Components/Snap-to-Grid
When you say components, do you mean web components (Polymer, polyfills etc)? Could you please point me to some articles or resources on components with SVG layers?
I really appreciate the example you provided for the snap-to-grid, it's very similar to what I had in mind in regards to a floorplan builder with some positional and layout consistency built in. FabricJS looks very powerful in that sense.
Is there a reason you used Fabric over Konva? What is the difference between them?
__
Floorplan builder/Reuse
From what I can tell, the only user account type that would have full builder access is the restaurant owner. Restaurant staff and customers would never touch the builder UI, they would just be working with a version of the "built" layout, via the embedded iframe. The builder would really only be accessed when the restaurant owner logs into their account, and effectively saves changes, and the iframe embed just updates accordingly.
The types of user tasks that the other two parties do - staff and customers - is really only interacting via the embedded floorplan.
It sounds like build-once and embed (owner) with the builder, and manage (staff) and interact (customer) via the embed. As an MVP, instead of having an embedded floorplan element that is clickable, where they can click on table/seat to reserve (customer) or reset (staff) I could just have a form that updates it and is reflected on the embed, whilst logging those things in the DB so that the owner can generate reports from. Perhaps those forms can be embedded in the iframe too - a reserve form visible to customers, and a reset/reserve form visible to staff.
You mentioned a composition/design pattern, do you mean like a reusable design element (a base builder) which can be extended with different features, per the user type? That makes sense, reuse and standardization is good to improve code reuse and UI look/feel. But perhaps with my above discussion, really there is just one builder, accessed by one user type.
__
Embed Security
That sounds promising, especially the server handshake. I was thinking, via the owners account, they would register the URL of their restaurant website, and perhaps the iframe embed code snippet includes something that checks the URL, otherwise displays some message like "This domain is not registered to display this floorplan. Please log in to your account to verify."
Can the embed code do this?
__
React/TypeScript
I will read up on those tutorials, thanks for taking the time to find some relevant tutorials. My basis of understanding is low enough that I'm not sure what to search for, but this ongoing discussion as really be mind opening.
I really do appreciate it!
1
You can make any component Snap. You may need to wrap it in Fabric container.
I don't remember why I chose Fabric over Konva. I am getting little busy with my freelance job. I suggest you do some R&D before selecting one.
Goodluck.
1
I need advice in Marketing if you could..
1
I am sorry Sofia, I am not good enough to advice in Marketing. I am techy guy.
You can directly post your marketing question in IndieHackers main forum, people are very friendly here.
1
I dont't have a project ... for now but I give you a positive feedback:
You sir, you are a gentlemen for you pro-bono action.
1
Thank you.
1
I'm looking for less of technical advice for building our product, but rather, a technical opinion on our product if you'd be willing to provide feedback. :)
I'm part of the team working on Cheddar, a usage-based billing API.
We differentiate ourselves with a few different things:
-We charge per transaction instead of as a percentage of revenue, like a lot of billing platforms
-We're payment processor agnostic, meaning you can switch your payment processor at any time if you get a good rate or if you'd like to have two or more at once, etc.
The biggest thing we use to differentiate, however, is technical: it's our fundamental billing architecture. Instead of your software communicating in a fixed with with your billing system via dollars and cents, our billing API tracks all of your software activity first (that you might not even be charging for) and then you can apply pricing plans to that usage data later.
The biggest benefit is that you can iterate your pricing plans and how you charge for your product without having to re-integrate billing code (ex. You can decide to switch from charging per-user to some other usage metric with a new pricing plan configuration that doesn't require you touching code).
What I'd like is your technical opinion and advice on is...
Not a complete tech question but I am going though your docs, will let you know by tomorrow.
1
Yea, I realize it wasn't a question regarding tech advice (ex., what tech stack/language do I use?), but I thought it was worth a shot to try to better understand an outsider's technical opinion on our product. Thanks!
2
I spent some time reading the docs. I really like its simplicity and straight to the point approach.
Minor UI bug: On firefox and Chrome the Language dropdown Icon is overlapping with Text.
Hi Kishore,
I would like some tips on how best to technically approach this idea, both an MVP approach, and a more extensive approach.
I would like to build a restaurant seating management UI, essentially having tables and seats set up per the physical restaurant layout, but done virtually. Additionally I'd like to be able to mark a seat/table as available or occupied, and for how long (time remaining).
The way this would work is I myself would build the "virtual restaurant" UI myself (I don't know how, your help here please) individually maybe using HTML canvas, or build my own "builder" (worthwhile?) to make the process more repeatable. And finally allow the restaurant to embed (code snippet) the visualization on their restaurant business site. The restaurant staff would be managing the available/occupied status via a secure account.
What's the most MVP way to achieve this - layout builder, embeddable interactive layout, update status via login.
Thanks for your time and generosity
This is how I will approach this kind of application.
Technology Stack
Firebase or AWS as backend, NodeJs. For login and registration I suggest using Firebase login but I wouldn’t recommend Firebase client database API, instead I would go with Firebase Functions for all server processing (Another advantage is later if you decide to go with DigitalOcean or other VPN you can easily migrate to NodeJs/Express Function.) For me RDBMS is the quickest way to build MVP but with Firebase you can only use NoSQL DB.
ClientSide tech: I don’t recommend directly using Canvas. You can create your own layout component with ReactJS but providing customization is hard and bug prone. Instead go with something like frabricjs (http://fabricjs.com/demos/). With FabricJS you can easily create predefined layouts and let restaurant owners pick from them or quickly make new ones as needed.(You can also create an SVG layout and import into FabricJS).
I used Fabricjs for Watermark.ink (with Angularjs) and it saved a ton of time in visual component placement and arrangements. There are wrappers for AngularJS and ReactJS. I suggest you go with React, it’s a much cleaner code, easy to maintain and extended.
Allowing the restaurants to embed code snippets is a bad idea. Not because of security but because of import conflicts and code errors. It is very difficult to limit or control that kind of code snippets. Instead give them an easy to drag-and-drop layout maker made with fabricjs.
Let me know if you want anything more.
Thanks for the feedback, Kishore. Much appreciated.
I have some follow-up comments and questions (alot).
Now I am unfamiliar with Firebase and it's full capabilities so will need to do more research on it. From a cursory search, Firebase is a paid service?
You mentioned AWS as an alternative to Firebase, and seeing how Firebase does not support a RDBMS, AWS would make sense then. Are there particular services I'll need from AWS that I should be mindful of?
I can concur with you about not pursing the canvas approach. Having only watched a couple introductory tutorials on canvas, it doesn't look to scaleable, in the sense of quickly reusing floorplan components - like a table, or chair image - to recreate a new floorplans for new restaurants, quickly. There's likely a way to speed this up using canvas, programatically, but I don't know it. And from my minimal knowledge of canvas as this point, the way I could conceive, would appear like reinventing the wheel over and over. Tedious and not scaleable.
With said, I will need to look into FabricJS. I had not heard of it until you mentioned it. And I definitely be more inclined to having custom layouts versus a set of predefined layouts, restaurants could choose from.
Correct me if I'm wrong, but by SVG layout and importing in FabricJS, do you mean using a drawing software like Illustrator to draw the floorplan, save as SVG, and import into JS? If I want to change the appearance of say a table or chair based on a change in status, will this still work? Or will the SVG remain static, and I'll need overlay a visual treatment for status changes?
And on the topic of embed code snippets, what I was thinking of was a once a floorplan has been designed and configured, programmatically generate a code snippet, that the restaurant can copy/paste into their site. From this approach, would there still be code errors? And what exactly are import issues?
Ideally, a drag-and-drop floorplan builder would be ideal. A restaurant to log in, use the builder to build their floorplan, generate a snippet, and embed the snippet in their website to render the floorplan. Or are you saying, they have the actual builder on their site?
As I would like to be able to aggregate and track the patterns and actions of availability changes for all client restaurants, I figured the embed approach, would allow me to track those changes via the embedded floorplan. Essentially a floorplan widget. A restaurant owner/staff logins into my service, updates a status, status is reflected on their website, and wherever they have the floorplan widget embedded. Does this make sense?
Lastly, aside from FabricJS, can this be done with vanilla JS or is a framework required - Angular, Node, React etc.? As you can see, I'm new to this.
Thanks, again much appreciated
Firebase has 3 versions - Free, Fixed($25) and Blaze(pay as you use). https://firebase.google.com/pricing/ If you want to have a payment system like stripe you have to choose paid version. If you are new to server setup, security etc I suggest you go with Firebase(only learning curve is NoSQL DB), using NoSQL is easy, but designing storage structure in a proper way is a pain. For simple applications you don’t need to worry about pricing. Blaze (pay as you go will only ask for your creditcard, it wont charge until you exceed the free limits.
You can check AWS RDS https://aws.amazon.com/rds/ You need to check with their pricing. You can also look at Microsoft Azure. If you looking for a cheaper option consider VPN like DigitalOcean Droplet (starting with $5 per month).
--
For MVPs and minimal users the price chart goes like this (I am not sure about the AWS/Azure limited free tier. I only used paid AWS and Azure)
Minimal User Price: Firebase(Free) --- DigitalOcean(or other VPN) --- Azure --- AWS
As the number of users reach to hundreds of thousands the price chart looks like
Millions of Users: DigitalOcean --- Azure --- AWS -------------------------Firebase
(Firebase is expensive once your user-base grows to millions). Once you gain millions of users I only see Azure or AWS as a viable option. Among AWS and Azure I felt Azure is the easiest to deal with AWS (pricing, setup, configuration gets super complicated after a level).
----------------------
You will save alot of time and frustration if you go with a Framework instead of building everything from scratch. (If your UIcomponent is simple, using Canvas directly maybe a better option). I have only used FabricJS (extensively for Watermark.ink ). I suggest you also look at https://konvajs.github.io/
----------------------
You can save your FabricJS Object(UI visual part) and export it as json or SVG. Then you can load those files(json or svg) into FabricJS. You can create a SVG file and import into FabricJS. I encountered some glitches while importing SVGs created with illustrator but for most of my needs it worked fine.
About Editing/appearance based on status: Yes you can do that but its tricky. As the underlying object is SVG you can change the color and few properties of those object. According to what I understood from your description I think that is not what you need. Changing the appearance of the SVG is not a right design. I suggest you one of the below two designs.
Have two different table objects(SVGs reserved-table-RED-svg and unreserved-table-GREEN-svg) one for unreserved and one for reserved and manipulate them based on the status.
Dynamic object
Create a SVG with non-modifiable UI (using illustrator etc) and import it into Scene(UI)
Create another top component (like RED, GREEN based on status)
Group these two components and use it as a single table object which changes display based on status.
I observed that layering two or more components (SVGs + other) works flawlessly than editing the imported SVG properties.
----------------------
I think I misunderstood your question before. What I understood now is, you want the Restaurant owners to design their tables layout on your site and then embed that tables layout into their restaurant website. Am I right?
For this you need to create an iFrame which restaurant owners will copy (from your site) and paste(embed) into their website. This will work fine, no issue here.
Just in case have a look CrossOrigin limitations ( CORS ) https://medium.com/@buddhiv/what-is-cors-or-cross-origin-resource-sharing-eccbfacaaa30
----------------------
I might have misunderstood your previous description. I thought it in the following scenario
Restaurant owners(owner) register and login into your site.
Design(build) their floorplan using a layout builder with custom visual components example:-
Layout builder asks questions like how many tables ? how many chairs per table? Table color? etc...
Owner will drags and drops table on the layout and save it.
Owner get the iFrame code to paste it into their own website.
Restaurant user will visit the Restaurant site, select a table and timing, etc
Are end users( Restaurant users) not allowed to reserve a table directly? Are the restaurant owners website is only to display the reserved tables but not for reserving?
------------------------
There are two things here,
1- Developing a complete web app like user login, UI components etc: with vanilla JS is asking for future problems. Extending with new features, bug fixes, cross browser issues, etc are difficult with vanilla JS. Pure ValinallJS is suggested only for simple websites, yours is an application, you need to consider things like adding additional features, bug fixes, code maintenance, cross browser compatibility etc. (I am planning to write an article about frameworks, I will share it with you.)
The top 3 popular web frameworks I know are ReactJS, VueJS, AngularJS. Note: ReactJS takes time to master.
2- FloorPlan builder: Doing it with pure Canvas is error prone. With FabricJS or KonvaJS you will save development time, have tested and predictable behaviour.
Thanks again for your detailed response, Kishore.
It definitely helped clear things up. Alot of my original plans or ideas of the product and design/code/deploy strategy are based on my limited understanding from reading, and not so much doing.
__
Firebase, thanks for the explanation on what Firebase does, and the pricing structure. And per you point about setup and security, I have no experience with security, and being particular about ensuring security and user privacy, I'd like to be sure I can lock things down. In regards to that, what does Firebase offer/do to cover the security aspect?
I do expect to implement payments, subscription based and tiered. And from what I can see, Stripe is well regarded, but haven't looked much into alternatives. But it sounds like, with the paid Firebase plan, Stripe integration will be painless.
In regards to NoSQL, I haven't worked with NoSQL, but if it needs to be done, I can live with that. In regards to this restaurant app, is the data I'm working with or potentially collecting (restaurant metrics, date time etc) suitable for a NoSQL approach or is it a nonissue? I ask because I've read that certain content-types are better suited to NoSQL databases, versus a traditional RDBMS. Will launching with a NoSQL database, introduce migration issues should I want or need to switch to RDBMS in the future?
__
AWS/DigitalOcean
This is interesting to see a mention of a VPN. Just to confirm, you aren't speaking of a VPS (virtual private server, step up from shared served tier), since I've briefly used one with HostGator, and it turned out to be overkill for what I needed. If you mean VPN as virtual private network, then I am confused. I've never come across VPNs discussed with hosting discussions, so I apologize if I'm mistaken.
I guess I assumed that the go-to for hosting nowadays was cloud-pay-as-you-need. And for that matter was looking into the AWS free tier, but from your Firebase discussion, AWS free does not compete with offerings of Firebase free. It looks like Firebase, by design, is turn-key for an app whereas AWS is a lot of bolting services together.
Millions of users? Nah, very unlikely. But should that be a problem, I will or someone will have already foreseen and planned a hosting strategy (a good problem to have). But it's good to know that Firebase can be affordable for small and medium sized user bases.
__
Fabric/Konva/SVG
I will have to look into Konva too. My main area of confusion is understanding why they exist, or the primary problem they were designed to solve, but from your explanation it's coming clearer. The JS world is huge, and a lot of libraries and frameworks exist for niche solutions.
In regards to the SVG discussion, I think I follow you. Rather than dynamically changing the visual treatment of the SVG (limited control on what you can visually change), instead create multiple versions of the object for each possible status/variation, and just toggle their visibility/activity based on the status, correct? Like if status=A, set objecttype=objectB, else set objecttype=objectA.
__
Embedding/Floorplan builder
Correct. A restaurant would use my site to create a floorplan for themselves after which they can embed into their business site.
Depending on the finalized user flow and UX, the floorplan design process could start with a series of user questions, which then help guide the options available in the builder. Good point.
I personally would like to, for the MVP, be able to allow restaurants to use drag-drop builder, a self-service DIY approach. But if it's too complicated, for me at least, would there be an alternative to quickly do the floorplans myself using input from the restaurant, without a drag-drop builder UI (not scaleable, but doable on the shorter term), that isn't too tedious and inefficient.
Eventually, yes, I would like to expand features beyond just restaurant owners/staff but also customers. Including a reservation process. With that said, does that add much more complication beyond the approaches already discussed?
Again my limited understanding comes into play here, as I had thought iframes were deprecated and frowned upon nowadays, so it sounds like I'm mistaken on that too. Sounds like iframes is the right embed method. Are there other alternatives out of curiosity?
I will read that CORS article. Thanks for the reference.
__
Frameworks
That makes sense. As I am looking to be as time efficient and future proof as possible, I figured that with JS frameworks, new frameworks become vogue every couple years. And it becomes a job learning and keeping up with frameworks. Would vanilla JS in that sense be more future proof as it will have less dependencies and lower risk of deprecations?
I guess my mentality is build once, do minimal maintenance, and not have to constantly be needing to transition and rewrite things. Unless that is just a necessary evil of creating a secure, functioning app nowadays?
I am investigating the possiblity of making this a PWA, progressive web app, to get better mobile and offline UX and performance. This product doesn't sound complex or specialized enough to jusify an investment in a native app at this stage. Does this completely change what's been discussed/proposed?
I look forward to your framework article!
__
Thanks, I'm learning alot from you!
--- Firebase security:
With "serverless" solutions like Firebase. There is no server to manage (Google will manage,maintaine those servers, you just write your application code).Security, crash recovery, load balancing(for large applications) etc are all provided by Google.
Other alternative popular Serverless solutions are Microsoft Azure Functions, Amazon Lambda and Google Cloud Functions(this is different from Google Firebase).
--- NoSQL:
For your application it is not difficult to implement with NoSQL. If you are not aware of NoSQL it will take more time to think/understand in NoSQL style.
I don't like NoSQL DB's, but one small advantage is less code to write.
NoSQL DB is not a one-to-one data migration to RDBMS. The Nonsense of NoSQL is there is no data normalization, you duplicate everything. If you decide to start with NoSQL I suggest you don't giveup after few hickups like normalization issue, having Firebase manage your DB and letting you worry about code is a huge advantage for MVP.
--- AWS/DigitalOcean:
Very sorry to confuse you, I mean VPS (Virtual Private Server) not VPN.
AWS pricing is super confusing and some features look like workaround solutions. I am very happy using Microsoft Azure.
--- Fabric/Konva/SVG:
Imagine you are buiding an application like Online Photo Watermarking tool. If you try to implement drag and drop, resize,scale, rotate feature(bug free) that will easily take over a month. With FabricJS I am able to do it in few days. You can visit Watermark.ink the underlying draw area component is FabricJS.
Yes exactly, you can toggle and display what is needed. That is also easy to implement and modify. You can easily build a complex layers example:
[ { layer-1, backgroundType1-svg }, {layer-2, tableType-2-SVG }, { layer-3, tableReserved-SVG }, {layer-4, table-decoration-3-SVG } etc
-- Embedding/Floorplan builder
Visual Drag & Drop builders are complex, but making a simple floorPlan builder doesn't sound complex for me. I have to think about it.
I believe the most complex and attractive part of your application is visual floorplan builder and visual reservation UI. While designing the floorplan-visual-component you have to keep a note that some of the floorplan features are also going to be visible, editable(in future) for customers. Design it like baseFloorComponent and extend features in floorBuilderComponent and floorDisplayComponent. Otherwise you have to redesign and implement the customer facing parts separately.
iFrames are limited in features and styling so not a recommend approach. iFrames are still useful for some usecases, google still uses iframes for google forms.
Have a look at these suggestions https://stackoverflow.com/questions/8702704/alternative-to-iframes-with-html5
--Frameworks
I don't recommend vanilla JS, you will spend more time in bug fixing(like cross browser issues), reinventing things, etc.
For application like yours once you build it and it is working fine you don't need to worry about converting into newer framework. Unfortunately now-a-days who ever disagree will create a new framework. But there is a specific problem these frameworks are concentrating to solve. For simple applications any framework is better than vanilla JS. ReactJS is over kill for some applications, there is a steep learning curve(it is different from traditional web apps) and if you need to learn React Redux then you can dedicate a month for just understand it. I believe Redux is a complex solution for simplifying things :)
If you are not familiar with ReactJS go with AngularJS or Vue. Your FloorPlan component will greatly simplify if you use React kind of component approach, thats why I recommend it. Also you can use React and other frameworks together, just be-careful with data sharing across them.
If you develop in React you can share some part of the code while making a mobile application.
https://facebook.github.io/react-native/
I've been reading up on your responses, Kishore.
--
"Serverless"
Ah, that makes sense. I always thought AWS was synonymous with what you're describing as "serverless" but it's not. Is "serverless" synonymous with a turn-key app hosting solution or can you be serverless but manage it yourself?
Is AWS Lambda Amazon's competitor for Firebase? And Microsoft Azure is MS' Firebase competitor? Does DigitalOcean offer a similar service.
What made you decide to go with Microsoft Azure?
--
Database
Does Firebase offer more than the others - price, service, support - to warrant having to use NoSQL? I'm a little wary about going with Firebase/NoSQL out of convenience per se of having it managed by Google. Maybe I'm just old-fashioned and don't want "all my eggs in one basket" and feel "safer" with an RDBMS.
If I'm not mistaken from my reading on DB architectures, NoSQL are more performant at the cost of redundancy.
Having an ability to move my data around, is just comforting, but perhaps I'm overthinking it, especially per this particular product where it's really user data, restaurant data, floorplan/layout, and usage/reservation data.
Do AWS Lambda, Azure etc. also require a NoSQL database? Is NoSQL just required for "serverless" solutions?
--
VPS
No problem at all. Thanks for clarifying. So Virtual Private Server hosting still exists in this world with all the buzz about AWS, pay-as-you-go hosting offerings?
--
Fabric/Konva/Watermarking/SVG
I see! When you referenced your watermarking service, I wasn't sure what I was looking at. Specifically, which parts of it was powered by Fabric/Konva. So it looks like the majority of it, and some of the capabilities your application has, also shares my needs, and can be done with Fabric.
What's the difference between Fabric and Konva? Why did you choose to go with Fabric?
Previously we discussed using SVG as a method to get the floorplan out and embeddable. After looking around Fabric a bit, it looks like with drag-drop UI, after you've created the desired layout, you can export the layout as an SVG. Correct?
But if we are incorporating those different layers, for the different statuses, how does one manipulate the visibility of those layers, after it's been exported? I assume the layout is done using one layer/status, but when it goes "live" are the other layers triggered on the SVG itself? Sorry if this is confusing, I'm just trying to visualize.
Also, is it possible to establish a grid or a snap-to-grid capability on the drag-drop UI? For a floorplan, have some form of grid or dimensions helps with layout-spacing consistency and UX. Having said grid, once positioned in the canvas, can the locations/coordinates of each element be "saved" and then used to recreate the layout elsewhere (like the iframe embed)?
--
Floorplan builder
Having done some mulling, just going straight for the builder UI seems like the more time efficient way to do it.
With that said, seeing how there will need be user accounts - restaurant owner/staff and customers, and then god-mode (me), there needs to be some way to control who can do what, ie. different versions of the builder per se:
God-mode - I could build a floorplan using the builder on the behalf of a less-technically-capable restaurant. As well as any admin tasks
The restaurant owner, logs into my site, in their account, builds a floorplan on the builder, and exports the SVG/iframe to embed in their site. Additionally, could track metrics on occupancy etc - ex. which table is most popular and when. Even track customers for marketing outreach etc.
Restaurant staff, has a staff level account, associated to the owner, and have capabilities to reset, update, statuses of table occupancy and reservations. they would log into my site and be able to manipulate the floorplan, but not build/change layout. Layout is set by owner, but staff can interact with elements. Any of these changes would be reflected on the embedded widget on the restaurant business site.
Customers, would have an account, and access any restaurant's floorplan, but is limited to reservation placement and cancellation tasks. Their changes/updates are reflected on the specific restaurant's site.
Having written this out, it feels like there's a public floorplan embedded on the restaurant site which shows statuses in real-time, but interaction is done either through my site directly (via restaurant subpage) or if the customer is already logged in to my site (cookies?), can interact directly with floorplan on the restaurant site (the interaction-mode just changes - read-only to active).
Am I still only requiring one builder, but different views or SVGs to embed or be accessible, based on the user type?
--
Embed/iframe
One thing that is quite critical is to control who can embed what in their website. As in, the restaurant owner should only be able to embed it, on their website, and that the embed code can't be stolen from inspect-source and embedded elsewhere. It would not be good if a competitor restaurant could embed another's floorplan in their site, for whatever reason, malicious or not.
Can iframe embedding be made secure and trackable (who embedded it where)?
--
Frameworks/ReactJS
Thanks for pointing out that in most cases I could pick the most suitable framework - looks like React - and not have to worry about keeping up with the framework Joneses. It's quite a relief.
Honestly I was quite turned off by not using vanilla JS out of concern of using an outdated framework and constantly playing catch up. It looks like in my case, that's a nonissue.
Thanks for that.
I will need to read more on React, but at least I have a direction.
--
Thanks again, Kishore
Letting companies like Google/Firebase/Azure/Amazon manage the server is called Serverless. If you want to manage it yourself, you can do it with your own VPS.
Yes they are all competitors. I felt firebase is the quickest to start among them.
We as a group decided Azure(not me alone) because most of our applications are Windows based. But later started using Azure for our Linux systems too. I felt Azure is much nicer and cleaner than using AWS. Some of the AWS features are a mess, especially pricing.
And I am not sure about the performance side of NoSQL vs RDBMS. I read some of the NoSQL DB's are designed for better writes than RDBMS.
With Firebase there is not option for RDBMS, but with Google Cloud you can still use RDBMS Database.
Even though Firebase and Google Cloud are from Google they operate little differently and concentrate on different users. Firebase was an independent company which was primarily concentrating and providing mobile applications backend systems, data storage, analytics etc. Google acquired them and continued that as a separate service to Google Cloud. Some of the Google Cloud and Firebase inter-operate.
AWS, Azure, Google Cloud, DigitalOcean are all Virtual Private Servers. Except DigitalOcean others provide more features like Serverless, Functions, Lambda, etc.
--
Majority of what you see in Watermark.ink is FabricJS Canvas.
Yes you can export as SVG or as JSON object
You should create a custom component and use exported layers inside the component. The rendering/visibility code is inside your custom component.
Yes, check this http://jsfiddle.net/fabricjs/S9sLu/
Other questions I am not sure, need some R&D.
--Floor Builder
The design sounds good, but I can't answer without knowing complete features. Also it is not completely possible to have one builder which is extended on top of the previous user(access level). There are situations where some features maybe specific which doesn't need to be inherited, in such situations you may need a Composition(design pattern) kind of design.
--
Can iframe embedding be made secure and trackable (who embedded it where)?
Others can't tweak iframe code, if there is a dynamic code in it, it simply doesn't work. With clever tricks like server handshake you can also restrict displaying it on pre-registered domains only. For domains which are not authorized you can restrict.
--Frameworks/ReactJS
React takes some time to learn. VanillaJS is very difficult to manage and extend large applications. Your applications I believe is a bit complex, if I were you I will surely avoid vanillaJS. Have a look at Typescript.
Some of Robin tutorials are good, the following link provides a detailed How-to for developing Firebase-Authentication-React App.
https://www.robinwieruch.de/complete-firebase-authentication-react-tutorial/
Thanks again for your response, Kishore.
__
Serverless/Firebase/Azure/NoSQL/RDBMS
Thanks for clarifying. I will continue reading up on Firebase, and then potentially Azure/AWS should my product's userbase grows to a point where Firebase is economically unfeasible.
At this stage, the data I have in mind that will be saved/queried should be okay with NoSQL, at least, I don't foresee big issues with duplication. Thus making Firebase a viable option.
Also, thanks for clarifying what serverless means, meaning managed versus self-managed.
__
Watermark/FabricJS/Components/Snap-to-Grid
When you say components, do you mean web components (Polymer, polyfills etc)? Could you please point me to some articles or resources on components with SVG layers?
I really appreciate the example you provided for the snap-to-grid, it's very similar to what I had in mind in regards to a floorplan builder with some positional and layout consistency built in. FabricJS looks very powerful in that sense.
Is there a reason you used Fabric over Konva? What is the difference between them?
__
Floorplan builder/Reuse
From what I can tell, the only user account type that would have full builder access is the restaurant owner. Restaurant staff and customers would never touch the builder UI, they would just be working with a version of the "built" layout, via the embedded iframe. The builder would really only be accessed when the restaurant owner logs into their account, and effectively saves changes, and the iframe embed just updates accordingly.
The types of user tasks that the other two parties do - staff and customers - is really only interacting via the embedded floorplan.
It sounds like build-once and embed (owner) with the builder, and manage (staff) and interact (customer) via the embed. As an MVP, instead of having an embedded floorplan element that is clickable, where they can click on table/seat to reserve (customer) or reset (staff) I could just have a form that updates it and is reflected on the embed, whilst logging those things in the DB so that the owner can generate reports from. Perhaps those forms can be embedded in the iframe too - a reserve form visible to customers, and a reset/reserve form visible to staff.
You mentioned a composition/design pattern, do you mean like a reusable design element (a base builder) which can be extended with different features, per the user type? That makes sense, reuse and standardization is good to improve code reuse and UI look/feel. But perhaps with my above discussion, really there is just one builder, accessed by one user type.
__
Embed Security
That sounds promising, especially the server handshake. I was thinking, via the owners account, they would register the URL of their restaurant website, and perhaps the iframe embed code snippet includes something that checks the URL, otherwise displays some message like "This domain is not registered to display this floorplan. Please log in to your account to verify."
Can the embed code do this?
__
React/TypeScript
I will read up on those tutorials, thanks for taking the time to find some relevant tutorials. My basis of understanding is low enough that I'm not sure what to search for, but this ongoing discussion as really be mind opening.
I really do appreciate it!
You can make any component Snap. You may need to wrap it in Fabric container.
I don't remember why I chose Fabric over Konva. I am getting little busy with my freelance job. I suggest you do some R&D before selecting one.
Goodluck.
I need advice in Marketing if you could..
I am sorry Sofia, I am not good enough to advice in Marketing. I am techy guy.
You can directly post your marketing question in IndieHackers main forum, people are very friendly here.
I dont't have a project ... for now but I give you a positive feedback:
You sir, you are a gentlemen for you pro-bono action.
Thank you.
I'm looking for less of technical advice for building our product, but rather, a technical opinion on our product if you'd be willing to provide feedback. :)
I'm part of the team working on Cheddar, a usage-based billing API.
We differentiate ourselves with a few different things:
-We charge per transaction instead of as a percentage of revenue, like a lot of billing platforms
-We're payment processor agnostic, meaning you can switch your payment processor at any time if you get a good rate or if you'd like to have two or more at once, etc.
The biggest thing we use to differentiate, however, is technical: it's our fundamental billing architecture. Instead of your software communicating in a fixed with with your billing system via dollars and cents, our billing API tracks all of your software activity first (that you might not even be charging for) and then you can apply pricing plans to that usage data later.
The biggest benefit is that you can iterate your pricing plans and how you charge for your product without having to re-integrate billing code (ex. You can decide to switch from charging per-user to some other usage metric with a new pricing plan configuration that doesn't require you touching code).
What I'd like is your technical opinion and advice on is...
If this makes sense?
Is this architecture obviously compelling to you?
If our docs are compelling?
Thank you!
Not a complete tech question but I am going though your docs, will let you know by tomorrow.
Yea, I realize it wasn't a question regarding tech advice (ex., what tech stack/language do I use?), but I thought it was worth a shot to try to better understand an outsider's technical opinion on our product. Thanks!
I spent some time reading the docs. I really like its simplicity and straight to the point approach.
Minor UI bug: On firefox and Chrome the Language dropdown Icon is overlapping with Text.
Screenshot- https://i.imgur.com/uvakemS.png
The only minor suggestion is: along with cUrl, php, Ruby examples, you can provide nodejs as an additional option.
Thanks Kishore, that's really helpful. I appreciate you taking the time to point out the bug as well.