I noticed that as part of the device discovery exchange, device-desc.xml file contains a UDN value.
Can I use this as a unique id for that chromecast device?
You should be able to use the UDN as a unique identifier for a particular Chromecast.
UDN typically means "unique device name" and the format looks like a UUID which was made so that you can uniquely identify things.
As for your other question about how to collect metrics, it depends on what you want to collect and why.
If, for example, you wanted to figure out what the social usage of your app was (assuming that you had some multi-participant logic) you could track usage by device and see if certain devices are hubs of social activity and see usage patterns. This might help you figure out what sorts of features you need and help you determine if you have repeat users or if you have repeat locations meaning that you may want to persist state in different places.
However, I would suppose that the most value can be gained by attaching behaviors to users. It may be better to track application sessions and attach data to a session which would indicate how users interacted with your app and with each other. You can define a "session" in multiple ways. It could be the duration of a user's "joining" of a receiver app or the life of the receiver app itself. Probably a bit of both would be best.
Related
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
I wonder if you can help. I am writing an order system and currently have implemented an order microservice which takes care of placing an order. I am using DDD with event sourcing and CQRS.
The order service itself takes in commands that produce events, the actual order service listens to its own event to create a read model (The idea here is to use CQRS, so commands for writes and queries for reads)
After implementing the above, I ran into a problem and its probably just that I am not fully understanding the correct way of doing this.
An order actually has dependents, meaning an order needs a customer and a product/s. So i will have 2 additional microservices for customer and products.
To keep things simple, i would like to concentrate on the customer (although I have exactly the same issue with products but my thinking is that if I fix the customer issue then the other one is automatically fixed also).
So back to the problem at hand. To create an order the order needs a customer (and products), I currently have the customerId on the client, so sending down a command to the order service, I can pass in the customerId.
I would like to save the name and address of the customer with the order. How do I get the name and address of the customerId from the Customer Service in the Order Service ?
I suppose to summarize, when data from one service needs data from another service, how am I able to get this data.
Would it be the case of the order service creating an event for receiving a customer record ? This is going to introduce a lot of complexity (more events) in the system
The microservices are NOT coupled so the order service can't just call into the read model of the customer.
Anybody able to help me on this ?
If you are using DDD, first of all, please read about bounded context. Forget microservices, they are just implementation strategy.
Now back to your problem. Publish these events from Customer aggregate(in your case Customer microservice): CustomerRegistered, CustomerInfoUpdated, CustomerAccountRemoved, CustomerAddressChanged etc. Then subscribe your Order service(again in your case application service inside Order microservice) to listen all above events. Okay, not all, just what order needs.
Now, you may have a question, what if majority or some of my customers don't make orders? My order service will be full of unnecessary data. Is this a good approach?
Well, answer might vary. I would say, space in hard disk is cheaper than memory or a database query is faster than a network call in performance perspective. If your database host(or your server) is limited then you should not go with microservices. Moreover, I would make some business ideas with these unused customer data e.g. list all customers who never ordered anything, I will send them some offers to grow my business. Just kidding. Don't feel bothered with unused data in microservices.
My suggestion would be to gather the required data on the front-end and pass it along. The relevant customer details that you want to denormalize into the order would be a value object. The same goes for the product data (e.g. id, description) related to the order line.
It isn't impossible to have the systems interact to retrieve data but that does couple them on a lower level that seems necessary.
When data from one service needs data from another service, how am I able to get this data?
You copy it.
So somewhere in your design there needs to be a message that carries the data from where it is to where it needs to be.
That could mean that the order service is subscribing to events that are published by the customer service, and storing a copy of the information that it needs. Or it could be that the order service queries some API that has direct access to the data stored by the customer service.
Queries for the additional data that you need could be synchronous or asynchronous - maybe the work can be deferred until you have all of the data you need.
Another possibility is that you redesign your system so that the business capability you need is with the data, either moving the capability or moving the data. Why does ordering need customer data? Can the customer service do the work instead? Should ordering own the data?
There's a certain amount of complexity that is inherent in your decision to distribute the work across multiple services. The decision to distribute your system involves weighing various trade offs.
I am developing an application utilizing the microservices development approach with the mean stack. I am running into a situation where data needs to be shared between multiple microservices. For example, let's say I have user, video, message(sending/receiving,inbox, etc.) services. Now the video and message records belong to an account record. As users create video and send /receive message there is a foreign key(userId) that has to be associated with the video and message records they create. I have scenarios where I need to display the first, middle and last name associated with each video for example. Let's now say on the front end a user is scrolling through a list of videos uploaded to the system, 50 at a time. In the worst case scenario, I could see a situation where a pull of 50 occurs where each video is tied to a unique user.
There seems to be two approaches to this issue:
One, I make an api call to the user service and get each user tied to each video in the list. This seems inefficient as it could get really chatty if I am making one call per video. In the second of the api call scenario, I would get the list of video and send a distinct list of user foreign keys to query to get each user tied to each video. This seems more efficient but still seems like I am losing performance putting everything back together to send out for display or however it needs to be manipulated.
Two, whenever a new user is created, the account service sends a message with the user information each other service needs to a fanout queue and then it is the responsibility of the individual services to add the new user to a table in it's own database thus maintaining loose coupling. The extreme downside here would be the data duplication and having to have the fanout queue to handle when updates needs to be made to ensure eventual consistency. Though, in the long run, this approach seems like it would be the most efficient from a performance perspective.
I am torn between these two approaches, as they both have their share of tradeoffs. Which approach makes the most sense to implement and why?
I'm also interested in this question.
First of all, scenario that you described is very common. Users, videos and messages definitely three different microservices. There is no issue in how you broke down system into pieces.
Secondly, there are multiple options, how to solve data sharing problem. Take a look at great article from auth0: https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/
Don't restrict your design decision to those 2 options you've outlined. The hardest thing about microservices is to get your head around what a service is and how to cut your application into chunks/services that make sense to be implemented as a 'microservice'.
Just because you have those 3 entities (user, video & message) doesn't mean you have to implement 3 services. If your actual use case shows that these services (or entities) depend heavily on each other to fulfil a simple request from the front-end than that's a clear signal that your cutting was not right.
From what I see from your example I'd design 1 microservice that fulfills the request. Remember that one of the design fundamentals of a microservice is to be as independent as possible.
There's no need to over complicate services, it's not SOA.
https://martinfowler.com/articles/microservices.html -> great read!
Regards,
Lars
I am creating a payment processing page for use via stripe and I want to be able to have my customers manages saved cards or use a new one. I am worried about being too forthcoming with some customer information and the possibility of exposing too much card information to my servers.
If I retrieve sensitive info like last 4, exp date, etc. should I be putting some means of encryption on it or is it completely fine to display or store pieces of that information for relationships server side on my end?
EDIT: New dev here be gentle :)
The only PCI-sensitive information is the entire card number and the CVC.
The card's brand, last 4 digits and expiry date are not sensitive. If you use Stripe, you can retrieve this information the card object's attributes, e.g. exp_month and exp_year, etc.
From a PCI compliance point of view, you don't need to do anything special to handle this data since it is not considered sensitive. My recommendation would be to either simply query the information from Stripe as needed, and discard it afterwards, or store it as-is into your database (in that last case, you'll probably want to use webhooks to make sure your DB is synced with your Stripe account).
In my app which allows users to sync the core data content across their multiple devices, how unique should I make the NSPersistentStoreUbiquitousContentNameKey?
I.e. should it be unique in the sense of having the device ID? So if a user is running an app on their iPhone it has one NSPersistentStoreUbiquitousContentNameKey and if they're running it on their iPad is has another NSPersistentStoreUbiquitousContentNameKey?
Or does it have just be unique from app to app? I.e. if I have App A, it has one NSPersistentStoreUbiquitousContentNameKey and App B has another NSPersistentStoreUbiquitousContentNameKey?
It's purpose is to uniquely identify the persistent store within a users account. So if an app will only ever have a single persistent store (like a todo list might) then every installation of that app can share the same value for this key, but if you want to have multiple persistent stores then each one will need a unique key value here. Does this help?
From apple docs:
The content name is used to identify the store across different
devices so that transactions are synced consistently with the
potentially many instances of that persistent store file across all
the devices. For this reason, you must make sure you provide a unique
name for each store—for example, a UUID.
https://developer.apple.com/library/IOs/releasenotes/DataManagement/RN-iCloudCoreData/