I like how I've seen in Facebook posts where you can leverage reactions to be the voting mechanism.
I think if I wanted a poll, I would create two comments in my post and then direct people to heart the one to cast their vote. This is how I would work within the limitations of the current system if I wanted polling functionality.
I think I would much rather have a liquid tag to support a third party polling system that an integrated polling system in DEV.to. Which third-party polling service? Uncertain.
As a Developer
The DEV.to codebase is unwieldy and putting on my Solutions Architect hat I would hope this polling feature would be an isolate micro-application powered by lambdas (serverless functions) and the dat store elsewhere (DynamoDB) than part of the Rails codebase and schema.
The serverless functions could still sit within the DEV.to repo just not as a Rails application.
When I saw the launch of listings, I thought, this too would benefit by being its own isolate application. I have yet to check if its part of the single Rails codebase or is isolated.
I hope to see improvements over the core-functionality over new features and wish I had more time to work on these on boring tickets.
As it currently stands, we're definitely a team shaped to implement the majestic monolith approach, but as we evolve it's certainly a possibility that we would break things up into services where appropriate.
This feature could have been done that way but I think we're about a year away from being able to adjust our overall architecture approaches (if I were to guess).
As a company that has to keep taking some chances and maintaining momentum on new features as well as ironing out existing functionality, we have to take educated guesses and hope to be right on average most of the time.
We're at a place where our state of "core functionality ironed out and bug-free" status is better than ever, and we will have to maintain balance as we land on new plateaus in our evolution.
You definitely bring a lot of good insight when you dip into the code with opinions—and it's sometimes tough to balance "finding the right approach" with "settling on the practical approach in the moment". Your ongoing feedback and contribution is definitely welcome.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a Content Creator
I like how I've seen in Facebook posts where you can leverage reactions to be the voting mechanism.
I think if I wanted a poll, I would create two comments in my post and then direct people to heart the one to cast their vote. This is how I would work within the limitations of the current system if I wanted polling functionality.
I think I would much rather have a liquid tag to support a third party polling system that an integrated polling system in DEV.to. Which third-party polling service? Uncertain.
As a Developer
The DEV.to codebase is unwieldy and putting on my Solutions Architect hat I would hope this polling feature would be an isolate micro-application powered by lambdas (serverless functions) and the dat store elsewhere (DynamoDB) than part of the Rails codebase and schema.
The serverless functions could still sit within the DEV.to repo just not as a Rails application.
When I saw the launch of listings, I thought, this too would benefit by being its own isolate application. I have yet to check if its part of the single Rails codebase or is isolated.
I hope to see improvements over the core-functionality over new features and wish I had more time to work on these on boring tickets.
Feedback super welcome as always Andrew.
As it currently stands, we're definitely a team shaped to implement the majestic monolith approach, but as we evolve it's certainly a possibility that we would break things up into services where appropriate.
This feature could have been done that way but I think we're about a year away from being able to adjust our overall architecture approaches (if I were to guess).
As a company that has to keep taking some chances and maintaining momentum on new features as well as ironing out existing functionality, we have to take educated guesses and hope to be right on average most of the time.
We're at a place where our state of "core functionality ironed out and bug-free" status is better than ever, and we will have to maintain balance as we land on new plateaus in our evolution.
You definitely bring a lot of good insight when you dip into the code with opinions—and it's sometimes tough to balance "finding the right approach" with "settling on the practical approach in the moment". Your ongoing feedback and contribution is definitely welcome.