We needed a sophisticated help center solution as we provide extensive support with 3 support team tiers. Intercom is more about messaging and automation. We needed sub-tickets, tasks, reminders, SLAs, automation, and strong API connections. That's why we have chosen Zendesk and we are quite happy with that.
The diagramming program for everything. Open Source.
Features I love:
- Files can be saved not only in drawio XML format,
but also as
html- all without loosing meta information. Note: I recommend attaching
.drawioto the filename to make the actual file type obvious, e.g.
- Available as a Browser Application as well as a offline useable Desktop Application (available through automatic and awesome github releases).
- Object Anchors
The shapes I use for Network Diagrams are:
- Network / Cloud & Enterprise (for Server)
- Network / Cisco19 (for Network Components)
- Network / Veeam (for Backup-things)
It was all really intuitive and head-on start.
I recommend and show it to literally everyone. There is no exception.
Hello Dear Developers, I am a newbie in Full Stack Development, I have been assigned a full stack application that manages text and user data. I have started learning Node.js and I know some basics of Node JS. The Project is assigned to me by my University Professor. I and my team has developed a good Front End for our Website in React (we are familiar with JS). What Backend we should use?
Instead of using Node.js, as you are familiar with SPA I'd try to do as much logic as possible in the webapp. By using Firebase DB browser library, you can authenticate users with a variety of OAuth/password methods, store user data, and use DB authentication rules to grant read and/or write permission by various rules. With the right combination of Firebase tech, you can likely avoid any nodejs at all... (Unless it is a class requirement to have some nodejs, then maybe have a serverless cloud function that does some admin action like cleanup old data.)
There are two Firebase DBs: Firestore, and Realtime Database. Start with Firestore because it is the recommended technology.
I would definitely go with Strapi as a backend for a project like that. It already as great features like user signup/login with various providers and has a proper permission management. I has a very good API that is easy to use and data can be accessed with GraphQL if needed. I found it easy to run locally for development and the deployment process can be really easy as well.
Supabase is also an alternative I have tried once but it had less features than Strapi when I tried it at the time
A developer and project manager from our team X says the following about our use of Rails at i22:
"We use Rails to build stable and flexible backend systems. Rails is extremely good for managing data structures and quickly setting up new systems. It is the perfect base for most use cases."
I asked the same Team X member why the team prefers to work with Ruby on Rails, rather than Python and Django:
"Because Python is a scripting language and from my point of view not suitable for building stable web services. Python is for me rather good for scripts and fast small tools. Not for stable business applications. And if I want it fast I prefer Go."
I totally disagree with that.
Besides the X vs Y opinion based comparison, businesses should focus more on some technical analysis and Just In Time software design and architecture.
Of course all the decisions should take in consideration technical expertises available in the development team, because team retrain times and costs should be evaluated and compared to the benefits of a new technology adoption.
If performance is a concern, investing on some R&D to develop some barebone PoC "apples to apples" comparison should be considered.
This can help to mitigate technology adoption, and also retainment, risks and avoid the much bigger risk of opinion-based decision making (which, as a personal opinion made on available information in this case, is based on outdated knowledge and apples to oranges comparison - like comparing batteries included fullstack frameworks vs bare languages).
Even if all of these layers of analisys confirm an initial opinion all the insight generated will help the overall design and management of the product/project producing extended benefits during development.
thank you for your input. I would like to respond "very briefly" to your feedback :)
Technology decisions are neither dogmatic nor necessarily dichotomous at our company. Accordingly, your criticism is rather due to the orientation and mode of this platform, which calls for the A vs. B scheme.
We have a clear attitude towards technology decision making. At i22, the choice of technology belongs in the hands of the project teams. They decide - and no one else.
But we go even further. Teams work with us on their own entrepreneurial responsibility. They manage not only tech decisions, but also their resources, customer relationships and projects themselves. Because here, too, hierarchy would only slow down the process.
Who can decide faster and better which skills are needed and how priorities should be set, if not the experts in the project in close proximity to the customer?
Our customers deserve individual solutions for their needs. We don't just reach into the shelf and take care of every customer problem with a standard solution. Every tech stack is tailored - and to do that, we have to be flexible, technically adept, and fast in our decision-making.
tl;dr if we had a case where Python is the most effective and efficient tool for a solution from all perspectives, we develop with it. We do not decide dogmatically against Python, but in the use cases from the concrete team X.
Your explanation gives a really Agile and smart vision of your company, differently of what was my first impression (which had no context of the project).
Team and project are the most weightful voices in choice for a product architecture. I find that nowadays become more and more difficult to choose between same tier technologies/languages/frameworks, mostly because they have very similar level of features offered and developers experience. There is hardly an overall better solution for all the cases. If everything has to be diceded upfront risk is really high and that was my warning.
Good luck with your project!
Redis is an amazing in-memory #database. But that's all it used to be, a really amazing distributed hash table to get or set key-value pairs. But recently while consulting for a startup I came across Redis Enterprise and it totally blew my mind away.
I have never seen a big database company totally revamp its offerings. For example, MongoDb is still trying to find a way to monetize their DB by changing the license to Server Side Public License. ElasticSearch did something similar and that's why Amazon created OpenSearch(a fork of ElasticSearch).
What can Redis Enterprise do?
They introduced bloom filter and cuckoo filter as first class citizens. Bloom filter is probably one of the most underrated yet one of the most widely used algorithm I know of. Google Chrome uses Bloom filter to check if a URL exists in their malicious URLs Dataset.
Besides that, Redis also introduced a new JSON module that lets users save any JSON objects and then allows the users to run queries on any fields.
Redis Enterprise has a lot more modules such as TimeSeries, Streams, AI, and more.
The entire ecosystem is really new but it totally has the capability to replace a whole suite of document databases, #caches, and indexed search systems.
The only "con" would be the pricing. It's a bit expensive and also it's not #opensource but has Redis source available License(RSAL).
I am pretty sure some companies are already working on an open sourced alternative to Redis Enterprise and various modules.
It's just amazing to see how databases are evolving. I would have never imagined someone using Redis as their main database but it's happening.
What do you think? Would you trust #Redis with your Production load?
As we're developing a critical piece of software, type safety is very important to minimize the errors we have. While Python supports type hints nowadays, Go makes it much more easy to work with and allows us to be confident in the software we ship.
Take look at our code in our github
I chose Make in part because the Racket community has make files for projects that were easy to use and adapt to my project. The reality is Make is still the best cross-platform cross-ecosystem build tool. Sure you could use something more tailored to your language or framework. But who has a stack so simple it only has one language or framework in it? Not me, certainly.
pnpm is one of the newer additions to our frontend stack. We used
yarn for a relatively long time but recently decided to reevaluate its usefulness. pnpm caught our eye for its speed and more efficient disk usage, and even though it is less popular than its competitors, we decided to place a bet on it.
We chose Dapr so that our developers could leverage managed cloud resources without having to write "infrastructure as code" code. You can easily connect different providers for the same common abstractions, such as a State Store, a Secrets Store or a Pub/Sub mechanism. We don't use the Actors functionality, though.
I've been approached by a business consultant for programming a website + web application for his client, which is a logistics company. The web application will have a tracking system for tracking their GPS enabled fleet (400 tricks).
Kindly advise me which scaleable stack can I use for the back-end. I'm planning to use React for the front-end.
And by back-end, I also include the database. I'm considering PostgreSQL as the database system.
Spring is a good decision for your needs, but you should build correct microservice architecture for good scaling. Work with database can be easy with ORM (e.g. Hibernate) and migrations (e.g. Liquibase) If you need the best performance and scaling on frontend, you can use Angular or React.
Fauna is a serverless database where you store data as JSON. Also, you have build in a HTTP GraphQL interface with a full authentication & authorization layer. That means you can skip your Backend and call it directly from the Frontend. With the power, that you can write data transformation function within Fauna with her own language called FQL, we're getting a blazing fast application.
Also, Fauna takes care about scaling and backups (All data are sharded on three different locations on the globe). That means we can fully focus on writing business logic and don't have to worry anymore about infrastructure.
I have been using Firebase with almost all my web projects as well as SwiftUI projects. I use it for the database as well as the user authentication via Google.
Is it good enough?? I have learned MySQL but I'm not that comfortable…
So for user authentication and database should I keep using firebase or switch to MySQL or MongoDB?? Or any other combination?
I’m not an expert, but I can tell you some things:
- Firebase is a great option for a very simple to implement, fast and reliable authentication method. Nonetheless, the free authentications are limited, so if you will potentially have millions of monthly authentications, it’s probably best to take the time to build it into your app directly.
- MySQL is great for simple tables where the data structures are not too complex, but it lacks some speed when you are trying to retrieve time data series. Also, I believe it’s a bit more difficult to distribute.
- MongoDB is great when your information is a bit more complex and you need very peculiar data structures, nested data, dynamic structures, etc. For me at least, it’s a bit more complex to master than MySQL, but the freedom it gives you is incredible. It also performs super fast, especially with time data series, and if I’m not wrong, it’s more scalable.
In general, almost all technologies have their good things, it’s just a matter of what you want to do and then choosing the right ones.
Hey thank you for the advice… I’ll surely continue to use that… but as for database management Like the collection system in firebase is a little hard to implement for large scale apps where I need multiple databases … so should I use MySQL or MongoDB or can I do something similar in firebase??
When I am making a website, I do NOT use an online database, because APIs are hard to learn, and just writing to files is easier. So when I code a website, I write to files for a DB. Oh, and by the way, there isn't a single file for a DB, each key has a file, look at the tree below for an example.
database - --- key.txt --- other key.txt
Yea, I find that works really well for most use cases. Only if you want to store a really large amount of data does it make sense to use a proper database.
As an advanced user, I prefer Postgres over MySQL. MySQL was the first database I learned from my institute. I always have to undergo that infamous date and time dilemma many Java devs know. Both are adequate for a small project. When I worked on a project with a date and time-intensive data, I spent a lot of time dealing with the conversion and transition, leaving me frustrated. I tried Postgres to see how well it can perform. To my surprise, all became a breeze, and the transactions were faster too. I've been using Postgres ever since, and no more dilemma.
Hey, Alfred! I'm glad you made the switch over to Postgres! If you're looking for a highly reliable ORM, I would recommend Prisma, you can check it out at www.prisma.io - Have a great rest of your Sunday!
Thank you for the information. I will consider trying it sometime.
Creating a reliable, scalable app quickly has become much easier and more straightforward. The Microsoft extensions of the runtime libraries make implementing dependency injection, configuration, and logging very convenient and reduces time spent writing boilerplate code. LINQ makes working with data a breeze especially when you have data coming from a variety of sources. Although Entity Framework Core can be a bit much and takes some time to get used to, I think it is a great ORM overall and has a lot to offer. Possibly my favorite part of building .NET apps is the deployment options available. Deploying an app as a single-file, self-contained, executable has been a luxury when deploying to machines without .NET Framework installed and/or installing the latest version was not an option. Single file deployment bundles all application dependencies and the framework into a single executable. The only other file that needed to be distributed was the appsettings.json file. Hosting the app in a Windows Service is cool and definitely beats working with Task Scheduler. It's clean and simple, which is a nice break from the norm.
I had used Svelte in one of the projects a year ago. I found it's a compact and a sleek framework. However, I wonder why it is not being used like other frameworks. I would like to use it if there's an opportunity. Component development is a breeze. Any views on this or any opportunities in Svelte would be appreciable.
We originally had used Algolia for our search features. It's a great service, however the cost was getting to be unmanageable for us. Algolia's pricing model is based around the number of search requests and the number of records. So if you produce a large number of small records the price can quickly get out of hand even if your actual dataset doesn't take up that much space on disk. Spikes in internet traffic can also lead to unexpected increases in billing (even if the traffic comes from bots)
After migrating to Typesense Cloud we have been able to save A LOT of money without losing out on any of the performance we got from Algolia. I do not exaggerate when I say that our overhead for search is less than 25% of what it used to be. Typesense also has the following advantages:
Their cloud offering lets you configure your Typesense nodes and specify how many you want to spin up. This allows you to manage costs in a manner that is way more predictable. (You basically pay for servers/nodes instead of records and requests)
It's completely open source. We can spin up a cluster on our own servers or run it locally.
It was important for us to use IaC from the very beginning, since we'll be deploying multiple components to multiple environments, and we want those environments to be easily replicated.
While the pragmatic choice would have been the widely used Terraform, we decided to go with Pulumi, which offers a more familiar syntax to describe your infrastructure (the language of your choice, in our case, Typescript). It also has an interesting built-in way of hiding your secrets for you, which makes managing secrets securely a breeze compared to Terraform.
The start-up guides, tutorials and documentation in general for Firebase are pretty outstanding.
There is 1GB database storage for the free tier as compared to Supabase's 500MB. Not that I think there is anything wrong with Supabase, I intend to try it out someday.
Also if you are doing any sort of personal front-end project, even using a free cluster from MongoDB can be a lot of work and setup, with Firebase (specifically Fire store and Google Authenticator) the implementation of BaaS is quite easy to get up and running.
It's pretty easy to understand the Fires store security rules as well, and if you ever have a hard time trying to figure something out, there is good community support and YouTube tutorials for most topics.
Firebase is the go to solution for a backend environment for any iOS or Android mobile app. It's easy to setup and integrate. As well as containing a wide range of services to meet lots of different needs. The free service tier give you enough headroom to let you experiment and test before committing to the service.
In my experience the best basis for any software-based version management. Although GitLab is really fancy and has a lot of good functionality (especially when trying to figure out which branch went wrong where), I chose GitHub since I am working on this project largely by myself and like how easy and fuss-free it is to share and fork.
We searched an effect monad to replace
scala.concurrent.Future and move our tech stack away from 'Scala as better Java'.
The requirements for the replacement were:
- Battle-tested & documented;
- Fiber-safe (not leaking concurrent resources).
ZIO was picked for the following reasons:
zio-magic) that enabled us to structure the application & do DI in a functional way;
- Typed error channel for safer handling of business-logic exceptions;
Schedulerand retries / cancellation;
- Steeper learning curve when compared to cats-effect.
Render is just a simplified frontend for AWS. You don't save any money in the long run and it closes a lot of doors for you if you want to use Infrastucture as a service like Terraform or Pulumi. If you only have one service you want to deploy and you're sure your stack won't grow then maybe I could recommend Render.
We use Redis as common in-memory cache for our distributed php processes. Since it also provides message-queue functions and was already in our stack, we didn't use an alternative like RabbitMQ for async handling. We have a multi-instance setup (configured via Ansible) on our maschines. High-Availaibility is configured via Redis Sentinel and HAProxy. The HAProxy-HAProxy setup is also responsible for SSL encryption. We could not use twemproxy since not all commands our application uses are supported.