I'm setting up a blockchain database using bigchaindb for an ecommerce platform. Although, it's more like a secure backup. My application already runs on a SQL database. The blockchain database saves data in the form of assets and transactions in mongodb. The bigchaindb also provides all it's data via a public API. Later, I also want to query this database.
I tried searching for it, but didn't get a dedicated discussion on database design for e-commerce on blockchain. If you know any such article out there, let me know, it'll be helpful.
As per my personal assertions:
Every information like, the user_profile, order, products, reviews etc can be saved in the form of assets. Moreover, operations like transferring product from the seller to the customer can be saved as transactions. Also, a customer creates a review as an asset, while putting the review on the product will be a transaction.
Of course, I will need to create Key-Pairs as identities for individual users, but I think I shouldn't save it in the blockchain, as it's data is accessible by the public API. So, I can save it in the actual SQL database of the application.
Do you think it's the best way? Any suggestions from your side?
I am not sure you can have a "schema" in a / any blockchain. For your purpose, which I believe is little strange https://github.com/ssbc/ssb-db should be enough.
Related
My fullstack React eCommerce application interacts with Stripe using my Express backend.
I need the client to be able to perform CRUD operations on products and orders, and as such they are currently stored in my mongoDB database.
However, I have discovered that interacting with Stripe's API is significantly easier if products (and thus orders) are stored on their database too.
As such, I am considering using both databases as sources of truth. However, this means that every CUD operation on one would need to be reflected in the other, making things more complex.
What is the best approach to this predicament? Thank you!
It really depends on your use-case and how you'd like to structure your integration. You're correct that it would make it easier to integrate with Stripe's API if you have the products and other information stored on Stripe. Stripe does provide a way for you to listen for any changes made to an object and update your own database accordingly using Webhooks [1].
You can build a webhook endpoint and listen to a variety of events in order to receive updates in real-time. This would allow you to maintain your own database without worrying about writing a script that polls API to retrieve the latest state of data/objects.
[1] https://stripe.com/docs/webhooks
I am creating accounting/invoicing software and my database is in postgreSQL. Should I create a separate database for each user since the data is sensitive financial data? Or is having a user foreign key secure enough? If I am hosting the database on aws I understand that I could have a few db servers across multiple availability zones and regions so that if one is compromised it wouldn't effect everyone even if many users have info stored in a single database. Is this safe enough? Thanks!
In general no. Encrypt the data so that if someone exfiltrates a dump they can't actually use it without the decryption key. If you're worried that someone with admin access can see the user's information then you might want to consider a user-level encryption for all fields related to personally identifiable information.
There are few ways you could go about it but I wouldn’t create a new DB for every customers. It will be too expensive and a pain to maintain and evolve.
To me, this sounds like you are creating a multi-tenant application.
I’d personally use the row-level security feature in Postgres (see this article) or create a separate Schema for each Customer.
You can add an extra layer of protection with encryption at rest. AWS support it (link)
I am trying to shift towards serverless architecture when it comes to building REST API. I came from Ruby on Rails background.
I have successfully understood and adapted services such as Api Gateway, Cognito, RDS and Lambda functions, however I am struggling with putting it all together in optimal way.
My case is the following. I have a simple user based platform when there are multiple resources related to application members say blog application.
I have used Cognito for the sake of authentication and Aurora as the database service for keeping thing like articles and likes..
Since the database and Cognito user pool are decoupled, it is hard for me to do things like:
Fetching users that liked particular article
Fetching users comments
It seems problematic for me because I need to pass some unique Cognito user identifier (retrieved during authorization phase in API gateway) to lambda function which will then save the database record with an external reference to this user. On the other hand, If I were to fetch particular users, firstly I must fetch their identifiers from my relation database and then request users details from Cognito user pool..I lack some standard ways of accessing current user in my lambda functions as well as mechanisms for easily associating databse record with that user..
I have not found some convincing recommended patterns for designing such applications even though it seems like a very common problem and I am having hard time struggling if my approach is correct..
I would appreciate some comments on what are some patterns to consider when designing simple user based platform and what are the pitfalls of my solution. Any articles and examples will also be very helpfull.
Thanks in advance.
These sound like standard problems associated with distributed, indpependent, databases. You can no longer delegate all relationships to the database and get a result aggregating them in some way. You have to do the work yourself by calling one database, then the other.
For a case like this:
Fetching users that liked particular article
You would look up the "likes" database to determine user IDs of those who liked it, then look up the "users" database to determine user details such as name and avatar.
Most patterns follow standard database advice, e.g. in the above example, you could follow the performance-oriented pattern of de-normalising - store user data such as name and avatar against each "like", as long as you feel the extra storage and burden of keeping it consistent is justified by the reduction in queries (probably too many Likes to justify this).
Another important practice is using bulk queries to avoid N+1 queries. This is what Rails does with the includes syntax, but you may have to do it yourself here. In my example, it should only take two queries because the second query should get all required user data in one go, by querying for users matching the list of user IDs.
Finally, I'd suggest you try to abstract things. This kind of code gets messy fast, so be sure to build a well-encapsulated data layer that isolates application code from dealing with the mess of multiple databases.
I plan to design a system with Dreamfactory as the user management server while a separate REST server for social feed. Dreamfactory will have its own MySQL database for storing user info while the social feed will use MongoDB.
Is this a good system design? I'm new to this as I'm using both open source platform for two different purposes; social feed and user management.
It's difficult to answer your question without knowing requirements to the system. I was going to ask you why storing users in MySQL, but all the same I can ask why using MongoDB or product XXX ;)
There is no silver bullet in programming. Tool is chosen from requirements, not vice versa.
If you do not need to relate data, do not need transactions and does not care about data consistency at all, why go why relational databases? Solutions like AeroSpike or just Redis (yes, it can be persistent too) can give you much higher read/write rate.
Well, I suggest you go write a document, containing your system description, think of load this system is going to have. May be you will decide, that storing data in CSV files is ok for you (joking ;) )
I'm developing a REST API using Zend Framework 1.12.3.
I have to implement subscriptions for different types of plans (i.e. Basic and Premium), each plan having different privileges (e.g. Premium may offer instant, daily and weekly SMS notifications, while Basic may offer only weekly SMS notifications).
Also, there may be custom plans only for certain clients.
I've added a column in the users table called subscription, but what I cannot figure out is where to save the privileges for each subscription plan.
Should I save these privileges directly into the DB (i.e. create a table called subscriptions, and another one called subscriptions_privileges having as columns subscription_id, privilege_name and privilege_value), or would it be better if I save them into the config file?
Thanks
Note: Actually this question is not linked with Zend Framework, it is system architecture question.
Short answer:
it is much more easy to hardcode your subscription plans in your source code configuration files;
it is much more flexible to store this data in database (you can create some administration panel to allow managers to manage them, track history of plan changes, use these data in analytical SQL queries). Theoretically you can deal with all this stuff through reading and writing to your config files, but databases are just the exact tool for these tasks.
P.S.: You can add separate layer of abstartion in your application. Use model objects for your subscriptions which can be populated either from database or from your hard-coded config files using different adapters.