The fact that one can have multiple "views" of a single collections means they can be "easy" to search: by building "secondary" collections / dictionaries of item "references" over the primary collection.
A tree view, as it's base, uses a list view; which is a "flat" structure.
The "nodes" are indented list items. The "collapsing" is controlled by toggling visibility.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
I was suggesting alternatives that should be explored before deciding on a path.
Gerry Schmitz wrote:
The fact that one can have multiple "views" of a single collections means they can be "easy" to search: b
Could be. But that depends on actual business needs.
Gerry Schmitz wrote:
A tree view,
Just to be clear this is a parent/child structure which could be implemented as a tree.
And searching tree structures based on parent/child structures will be 'slow' in some sense of the word. It is quite possible that the business needs, to which this post is insufficient to describe, might allow for a different structure which would provide better performance, based on the business needs.
Alternatively should I use a model structure instead of a json string?
I would use a model class for consistency and validation purposes, if nothing else. How you hydrate that model really doesn't matter (as far as the utility of the model class goes, at any rate). Additionally, if you ever intend to serve the data in a RESTful format, it will make that transition a lot easier. You should be able to process that model mapping fairly easily in your DAL.
Mycroft Holmes wrote:
Can I also host the web api on Azure.
Yep. In fact, you could skip the WebAPI app entirely if you use the Azure CosmosDB, but that's only useful if an object store will serve your needs.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
I have this that I want to create an API for and would like to do so using micro services.
I have people that are part of teams. Each team has a backlog with workitems in it.
I was thinking of creating the following microservices
GET - Return a list of person
POST - Create a new person
GET - Return the person represented by PersonId
PUT - Update person represented by PersonId
DELETE - Delete person represented by PersonId
GET - Return a list of teams
POST - Create a new team
GET - Return team represented by TeamId
PUT - Update team represented by TeamId
DELETE - Delete team represented by TeamId
Would do the same for Backlog and WorkItem.
The question I can't decide is where should the code go that returns the people in a given team? I mean should I have something like /team/12/members with a GET method that return the people in that team? That would make sens, but then, it would mean that the Team service would need access to the Person database, which violate microservice pattern.
Same, where would the code go to add a workitem to a backlog? /backlog/4/workitem with a POST looks reasonable to me..
So what is the normal way to deal with 0 to many relationship in the microservice world?
Basically, I agree with Eddy Vlungen. What I would like to add is that in your example your microservices are too granular. Naturally you should split your microservices by business capabilities, not by entities.
In all the docs, it's said that Node makes use of non-blocking I/O.
I guess this is not something totally new. All high-performance servers have been using the same. Even on OS level or network level.
What's making Node.js claim this "non-blocking" tag so much?
I was thinking Apache/IIS or any servers meant for high-volume connections, should be using non-blocking I/O. (i.e I/O port completion model for IIS on Windows).
I still believe IIS should be using IOCP internally, but may be only to a limited extent? as the documents say traditional Servers (Apache/IIS) does create 1-to-1 thread for each client.
It's a bit puzzling, why Microsoft did not think about a Node like pure-Single-threaded solution for servers.
Summary of questions:
1. IIS is really a dumb, 1-to-1 thread spawning server for every connected client?
2. Why Microsoft couldnt think of a Node model for web server, when I/O port completion has been so widely used in so many enterprise level network, I/O frameworks?
On the OS level it is not "non blocking IO", but simply threads and fibers.
I meant OS objects, i.e Pipes, File, Sockets or anything that's compatible to work with IOCP.
Eddy Vluggen wrote:
Yeah just saying about the architecture it's providing for scalable solutions.
Eddy Vluggen wrote:
Yes and no. If it is serving a picture, it doesn't need 40 threads for that. IIS also serves applications, which may launch their own threads.
But Microsoft is now, happily embracing Node. I was just thinking why they couldnt think of doing this by themselves. And I was believing IIS puts IOCP to max use and an invention called "Node.js" would never be a surprise.
There already was an IIS lite; there was both IIS Express and PWS.
If IIS was a rhino, IIS express & PWS were baby-rhinos. I was just wishing for a cheeta or a baby cheeta.
Eddy Vluggen wrote:
With most of the world running Windows, that sounds far-fetched at least.
Where Microsoft leads today, exactly? OS/Office? this is primarily because of the 80's , 90's market-share establishment.
Anyway, there's still some bits of 'ms-fan-boy' left in me. That's why I'm wishing they do some "breakthrough" technology. Keeping aside OS & office tools, of course, Microsoft is following the industry lead by Google ,Amazon & co.
The only thing that reminds me of something totally good & breakthrough from MS , might be the introduction of MVVM pattern to the world. That the whole industry is following in one or other ways.
And possibly, Visual Studio Code IDE - it definitely made a punch into open-stack world.
These are all just good!. But a total industry leading tech, MS can easily do, if they innovate better.
Having thorough expertise over non-blocking I/O, IOCP, MS should have done it first, Before someone else could do a thing called "Node.js".
I don't know on what basis lots of reviews were shared in tech-websites, highlighting node's superior scalability and performance over .net/IIS , Php/Apache. They quote a lot of companies who took advantage of moving to Node.
But the above article explains things neat. I might do a benchmarking myself to see it in action.
Last Visit: 3-Apr-20 20:15 Last Update: 3-Apr-20 20:15