3 ms·

What would you have liked to see differently in the article? More explanation? More examples? I would have written a more technical article, but it probably wou

What would you have liked to see differently in the article? More explanation? More examples? I would have written a more technical article, but it probably wouldn't have been the best fit for ComputerWeekly.

PaulHoule 4y ago
I think a lot of times when people write guest or sponsored articles the usual processes which lead to quality for advertising or editorial aren't followed. You're selling a technical product which many people don't understand the need for, leaving the details out puts you in a place where you make vague and unsupported statements, the real answer to that is going to be refining your messages over and over until they get good. Developing back end systems that provide an API over a relational, object or graph db has been a big part of what I do for the last decade. I don't think the coding is particularly difficult but there is a lot of it. I count 135 tables on the system I am working on today and there are more views, foreign tables, and other objects in that database. If there is a special challenge it's that an API like that always has some cross cutting concerns such as authentication, authorization, logging, data integrity and such. Because it is such a big job it would be rational to say a 20% improvement in development time would be impactful (save two months a year) but it's a tough sell because of the cost and risk of transitioning the system and/or trying something new. On one level I'm enthusiastic about low/no code products that are ontology driven but most of us have the experience that, someday, a system like that will answer you "you can't get to there from here". So that's more work for you to overcome. Examples and specific details are important. A business-driven example would be good to see, so would be a more technical example where your product vastly simplifies the code. I'd love to see testimonials by engineers or managers about the troubles they have with the status quo and how your product helps. (There is always the horror story of the API that was implemented w/o proper access controls.)
- ovaistariq 4y ago
  I am focusing more on newer applications at this point than existing applications that need to be migrated over. What if you build a new app where the interface with your data is simple? You have CRUD APIs that you integrate directly with the app. Your app needs full-text search capabilities, and it comes out of the box. You don't have to spin up ES and figure out the data shipping story. What if you are building an async processing flow and you simply have to define your event handlers? The async pipeline gets built up for you automatically and the event handlers are executed based on your business logic. If I am able to provide all of this abstraction to you, then suddenly you are not just 20% productive, you are 100% more productive. Because instead of doing DevOpsy stuff you ended up focusing purely on your application code. That's what we are looking to achieve with Tigris.

PaulHoule 4y ago

I think a lot of times when people write guest or sponsored articles the usual processes which lead to quality for advertising or editorial aren't followed. You're selling a technical product which many people don't understand the need for, leaving the details out puts you in a place where you make vague and unsupported statements, the real answer to that is going to be refining your messages over and over until they get good. Developing back end systems that provide an API over a relational, object or graph db has been a big part of what I do for the last decade. I don't think the coding is particularly difficult but there is a lot of it. I count 135 tables on the system I am working on today and there are more views, foreign tables, and other objects in that database. If there is a special challenge it's that an API like that always has some cross cutting concerns such as authentication, authorization, logging, data integrity and such. Because it is such a big job it would be rational to say a 20% improvement in development time would be impactful (save two months a year) but it's a tough sell because of the cost and risk of transitioning the system and/or trying something new. On one level I'm enthusiastic about low/no code products that are ontology driven but most of us have the experience that, someday, a system like that will answer you "you can't get to there from here". So that's more work for you to overcome. Examples and specific details are important. A business-driven example would be good to see, so would be a more technical example where your product vastly simplifies the code. I'd love to see testimonials by engineers or managers about the troubles they have with the status quo and how your product helps. (There is always the horror story of the API that was implemented w/o proper access controls.)

ovaistariq 4y ago
I am focusing more on newer applications at this point than existing applications that need to be migrated over. What if you build a new app where the interface with your data is simple? You have CRUD APIs that you integrate directly with the app. Your app needs full-text search capabilities, and it comes out of the box. You don't have to spin up ES and figure out the data shipping story. What if you are building an async processing flow and you simply have to define your event handlers? The async pipeline gets built up for you automatically and the event handlers are executed based on your business logic. If I am able to provide all of this abstraction to you, then suddenly you are not just 20% productive, you are 100% more productive. Because instead of doing DevOpsy stuff you ended up focusing purely on your application code. That's what we are looking to achieve with Tigris.